Công thức tính trả thưởng pi và cách tính pi node bonus
Mình thấy có quá nhiều bạn cứ hỏi sao bonus thế này thế kia. Trong khi đó các dòng code đều dựa vào công thức toán học nhưng 2 máy giống nhau nhưng lại cho bonus khác nhau, là bởi vì node bonus liên quan đến tài khoản pi của bạn chứ không phải node bonus chỉ dựa vào mỗi cái cấu hình máy chạy node.
Tham khảo các cấu hình máy tính chạy pi node: https://it365.vn/pc-workstation/pc-pi-node
Theo như công thức (đoạn tô màu vàng) bên dưới được công bố trên “white paper” thì ta có thể thấy pi node bonus phụ thuộc vào:
- Security Circle: vòng tròn bảo mật
- Lockup: thời gian và số pi đã khóa
- Uptime_factor: thời gian bật node
- Port_open_factor: số port đã mở
- CPU_factor: số nhân CPU
Các mốc thời gian tính trong công thức là: 1 ngày, 30 ngày, 90 ngày, 180 ngày, 1 năm, 2 năm và 10 năm. Và các mốc thời gian này tính theo số phiên chạy, nghĩa là tính theo số lần bấm tia sét.
Chốt lại là để được node bonus cao thì bạn phải: bấm tia sét mỗi ngày, CPU thật nhiều core, mở đủ 10 port, node bật 24/24, khóa thật nhiều pi, và đủ 5 người trong Security Circle.
Cái lạ của mọi người là cứ chăm chăm vào node bonus, trong khi cái Referral Team thì dễ đạt hơn nhiều nhưng mình sẽ nói vào lần khác, mọi người có thể tìm hiểu thêm về MMO để tăng Referral Team.
————————————————————–
Mainnet Mining Formula
The goals of the Mainnet phase are to make further progress in decentralization and utilities, ensure stability and longevity, and retain growth and security. The new formula, as written below, incentivizes more diverse contributions of Pioneers to support these Mainnet goals while retaining the incentives to secure and grow the network. As before, it is meritocratic and expressed as the rate at which Pioneers mine Pi per hour.
M = I(B,L,S) + E(I) + N(I) + A(I) + X(B), where
- M is the total Pioneer mining rate,
- I is the individual Pioneer base mining rate,
- B is the systemwide base mining rate (adjusted based on the available pool of Pi to distribute for a given time period),
- L is the lockup reward, which is a new component of the individual Pioneer base mining rate,
- S is the the Security Circle reward, which is a component of the individual Pioneer base mining rate from valid Security Circle connections the same way as in the pre-Mainnet mining formula,
- E is the Referral Team reward from active Referral Team members the same way as in the pre-Mainnet mining formula,
- N is the Node reward,
- A is the Pi apps usage reward, and
- X are new types of contributions necessary for the network ecosystem in the future, which will be determined later, but will also be designed as a multiple of B.
In short, S and E remain the same as in the pre-Mainnet mining formula, while new rewards such as L, N and A have been added to the current formula. L is added as part of I; N and A are added as additional rewards calculated based on I. In other words, the network still rewards growth through E and security through S, while incentivizing Pioneers’ contributions to running nodes for decentralization through N, using apps for utilities creation through A, and locking up for stability especially during the initial years through L. Further, new types of rewards to Pioneers through X in the future may be added for building a fully functioning ecosystem, such as rewards for Pioneer developers creating successful Pi apps. B continues to exist over a long period of time while having a yearly cap to ensure longevity of network growth while maintaining scarcity. In fact, all the rewards can be expressed in B as follows.
Here,
-
- I(B,L,S) = B + S(B) + L(B)
- S(B) = 0.2 • min(Sc,5) • B, where
Sc is the count of valid Security Circle connections. - E(I) = Ec • 0.25 • I(B,L,S), where
Ec is the count of active Referral Team members. - L(B) = Lt • Lp • log(N) • B, where
Lt is a multiplier corresponding to the duration of a lockup,
Lp is the proportion of Pioneer’s mined Pi on the Mainnet that is locked up with the maximum being 200%, and
N is the total number of Pioneer’s mining sessions preceding the current mining session. - N(I) = node_factor • tuning_factor • I, where
Node_factor = Percent_uptime_last_1_days • (Uptime_factor + Port_open_factor + CPU_factor), whereUptime_factor = (Percent_uptime_last_90_days + 1.5*Percent_uptime_last_360_days(360-90) + 2* Percent_uptime_last_2_years + 3*Percent_uptime_last_10_years),
Port_open_factor = 1 + percent_ports_open_last_90_days + 1.5*percent_ports_open_last_360_days + 2* percent_ports_open_last_2_years + 3*percent_ports_open_last_10_years,
CPU_factor = (1 + avg_CPU_count_last_90_days + 1.5*avg_CPU_count_last_360_days + 2* avg_CPU_count_last_2_years + 3*avg_CPU_count_last_10_years)/4.Percent_uptime_last_*_days/years is the percentage of the last * time period when the individual Node was live and accessible by the network.
percent_ports_open_last_*_days/years is the percentage of the last * time period when the ports of the individual Node were open for connectivity to the network.
avg_CPU_count_last_*_days/years is the average CPU that the individual Node provided to the network during the last * time period.
tuning_factor is a statistical factor that normalizes the node_factor to a number between 0 and 10. - A (I)* =
log [
Σ_across_apps {
log(time_spent_per_app_yesterday_in_seconds)
}
] •
log [ log(
0.8 • avg_daily_time_across_apps_last_30_days +
0.6 • avg_daily_time_across_apps_last_90_days +
0.4 • avg_daily_time_across_apps_last_180_days +
0.2 • avg_daily_time_across_apps_last_1_year +
0.1 • avg_daily_time_across_apps_last_2_year
) ] • Itime_spent_per_app_yesterday_in_seconds is, for each Pi app, the total amount of time in seconds that the Pioneer spends using the app on the prior day.
Σ_across_apps sums up the logarithmic value of the Pioneer’s time_spent_per_app_yesterday_in_seconds across all the Pi apps.
avg_daily_time_across_apps_last_* is the average daily time in seconds the Pioneer spends across all the Pi apps in the aggregate during the last * time period.* Note that when any of the logarithmic functions returns an undefined value or a value below 0 (that is, when, the input to the logarithmic function is below 1), the formula resets the value of the logarithmic function to be 0 in order to avoid negative mining rewards or an error in the function.
- X(B) is to be determined in the future based on the new types of contributions, but will be a multiple of B and kept within the yearly supply limit along with other rewards.
As shown above, the expressions of S and E remain the same as in the pre-Mainnet mining formula, and will not be explained further here. Next, we will focus on explaining the changes to B, changes to I through L, and the additions of N and A.
Systemwide Base Mining Rate
Like in Pre-Mainnet mining, all of the terms in the Mainnet mining formula above can be expressed in Pi per hour and are designed to be a multiple of B. Hence, the equation can also be re-written as below. Every Pioneer can mine at least the Systemwide Base Mining Rate everyday, and will be able to mine at a higher rate if they also have other types of contributions that are calculated as multiples of B.
M = B • (1 + S + L) • (1 + N + E + A + X)
Unlike in the pre-Mainnet mining, B in Mainnet mining as in the formula above is no longer a constant across all Pioneers at a given point in time, but is calculated in real time and dynamically adjusted based on a yearly supply cap.
Given a yearly supply limit, it is impossible to keep a constant B like in the pre-Mainnet period because it’s unpredictable how much each Pioneer mines and how many Pioneers are actively mining during a period of time. The pre-Mainnet model was designed to incentivize growth during the beginning years to bootstrap the network. As the network achieves a certain scale, it also needs to ensure the overall health of the ecosystem. Therefore, an exponential issuance of the tokens through exponential network growth and a constant mining rate does not make sense any longer. The shift of B from being a constant to being dynamically adjusted throughout the year results from the need to incentivize Pioneers’ contributions meritocratically but also to keep the total rewards within a limit.
Thus, to solve the yearly limit problem while ensuring fairness for whoever mined Pi, B of a given day in the year is calculated as below. Here a day is defined as the last 24 hours before the moment a Pioneer starts a new mining session. Hence, different Pioneers will have slightly different days relative to their time of mining, and thus, potentially a slightly different B based on the calculation below. Each Pioneer’s B of their day stays constant through their mining session, that is, over the next 24 hours from the moment they start their mining session. B is calculated as follows:
- Divide the remaining total Pi supply of the year by the number of days left in the year to get day_supply based on the remaining yearly supply,
- add the multiples of B from all Pioneers actively mining within the last 24 hours, which represents a diverse set of Pioneers’ contributions, in the Mainnet mining formula above to get the sum_of_B_multiples of the whole network for that 24-hour window, and
- further divide day_supply by sum_of_B_multiples and 24 hours to get B of that specific mining session.
Hence, for a given day of the year,
B = day_supply / (sum_of_B_multiples • 24h)
Under this framework, B on different days of the year will be different depending on how many Pioneers mined in the last 24 hours as well as what and how much contributions they made to receive the extra multiples of B by running nodes, using utilities apps or lockups, etc. This model also addresses any uncertainty with having X(B)—future types of contribution rewards for Pioneers—in the formula. Regardless of how much X is going to be, it will be kept within the same yearly supply limit without increasing the total supply and will only affect the division of rewards among different types of contributions. This dynamic mechanism allows Pioneers themselves, in a decentralized way, to make sure that (1) the rewards do not exceed the yearly supply limit, (2) the distribution of the yearly supply does not end early in the year, and (3) the rewards are divided meritocratically.
For purposes of illustration, let’s suppose there are only two Pioneers on a given day and B is the mining rate (expressed in Pi/day for this illustration)—a constant during a specific Pioneer mining session, but dynamically adjusted across different days:
Pioneer 1 has no app engagement (A=0), is not operating a Node (N=0), has no security connections (S=0), and has no active Referral Team members (E=0). They are in their 11th mining session (N=10) and are locking up 100% of their mined Pi (Lp=1) for 3 years (Lt=2). Pioneer 1’s mining rate on this day is:
- M1 = I(B,L,S) + 0 + 0 + 0, or
- M1 = B + {2 • 1 • log(10)} • B + 0, or
- M1 = 3B
Pioneer 2 has no app engagement (A=0), is not operating a Node (N=0), has no lockup (L=0), and has no active Referral Team members (E=0). They have a full Security Circle. Pioneer 2’s mining rate on this day is:
- M2 = I(B,L,S) + 0 + 0 + 0, or
- M2 = B + 0 + {0.2 • min(Sc,5) • B}, or
- M2 = B + {0.2 • 5 • B}, or
- M2 = 2B
Here, Total Pi to be mined in the whole network on this day = M1 + M2 = 5B Let’s assume there are 500 Pi and 50 days left in the year.
Therefore, Total Pi available to be mined for this day = 500 Pi / 50 days = 10 Pi/day
Solving B based on the two equations above,
- 5B=10 Pi ⇒ B = 2 Pi/day (or 0.083 Pi/hour)
Accordingly, Pioneers 1 and 2 will have their actual mining rates as follows:
- M1 = 3 • 2 Pi/day = 6 Pi/day (or 0.25 Pi/hour)
- M2 = 2 • 2 Pi/day = 4 Pi/day (or 0.17 Pi/hour)
Pioneer Base Mining rate
By comparison, the individual Pioneer base mining rate in the pre-Mainnet mining formula includes only system-wide base mining rate and Security Circle rewards. At Mainnet, a new component, lockup reward, is added to individual Pioneer base mining rate I. Lockup rewards L, along with the system-wide base mining rate B and Security Circle reward S, constitute the individual Pioneer base mining rate I. Since I is used as an input to calculate all the other rewards, as a result, the Security Circle and lockup rewards enhance the total Pioneer mining rate by: (1) by directly adding to the individual Pioneer base mining rate and (2) by boosting the any Referral Team reward E, nodes reward N, and app usage reward A.
Lockup Reward
At Mainnet, the lockup reward is meant to support a healthy and smooth ecosystem and incentivize long-term engagement with the network, while the network is bootstrapping the economy and creating demands. It is an important decentralized macroeconomic mechanism to moderate circulating supply in the market, especially in the early years of the open market when utilities are being created. One important goal of the Pi Network is to create a utility-based ecosystem of apps. Transactions for real goods and services in the ecosystem, rather than just speculative trading, are intended to determine the utility of Pi. As we launch the Enclosed Network phase of the Mainnet, one of the main areas of focus will be to support and grow the Pi app developer community and nurture more Pi apps to grow. In the meantime, Pioneers can choose to lock up their Pi to help create a stable market environment for the ecosystem to mature and for more Pi apps to emerge and provide compelling use cases for spending Pi – to ultimately create organic demands through utilities.
The lockup reward formula is reprinted here:
L(B) = Lt • Lp • log(N) • B, where
Lt is the Lockup Time period multiplier of B.
- 0 → Lt = 0
- 2 weeks → Lt = 0.1
- 6 months → Lt = 0.5
- 1 year → Lt = 1
- 3 years → Lt = 2
Lp is the Lockup Percentage multiplier of B, where
the Lockup Percentage is the lockup amount over the Mainnet Balance transferred from one’s previous mining rewards (Lb), and the Lockup Percentage multiplier is as follows.
- 0% → Lp = 0
- 25% → Lp = 0.25
- 50% → Lp = 0.5
- 90% → Lp = 0.9
- 100% → Lp = 1.0
- 150% → Lp = 1.5
- 200% → Lp = 2
log(N) is the logarithmic value of the total number of previous mining sessions (N).
Pioneers will have the opportunity to voluntarily lock up their Pi to earn the right to mine at a higher rate. First of all, the prerequisite of the lockup reward is that the Pioneer must be actively mining. Without mining in the first place, there will be no lockup rewards for any inactive mining sessions, even if Pi is locked up. As expressed in the formula above, all that the lockup does is to provide multipliers to B, so there will be no lockup rewards if B is 0 (which means the Pioneers is not mining).
Secondly, the lockup reward is positively associated with the contribution to the lockup, i.e. the duration of the lockup time period (Lt) and the amount locked up. However the lockup amount is accounted for by the percentage of a Pioneer’s total Pi mined (Lp). The maximum Pi that a Pioneer can lock up is twice as much as their Mainnet Balance that got transferred from their prior mining in the mobile app (Lb), i.e. 200% Lb. The reasons for having a 2X maximum lockup amount of one’s transferred Mainnet Balance (Lb) are to 1) prevent exploitation of the lockup reward and 2) further encourage other contributions to the Pi ecosystem, such as further boosting their mining, running nodes and using apps. This, in a sense, favors Pioneers who mine and make other types of contributions to the network.
Thirdly, Log(N) offers a higher lockup incentive to Pioneers who have a long mining history and presumably a large transferable balance to lock up. While the lockup reward formula generally favors equality by accounting for not the absolute amount but the percentage of their transferred balance (Lp) — which allows smaller accounts with a short mining history to lock up small amounts and yet receive the same lockup reward multiplier as big accounts — we need to add a Log(N) factor that accounts for miners with a long mining history, to counterbalance the bias in favor of Pioneers with small balances and provide enough incentive for long-history Pioneers with bigger balances. However, the effect of mining history on lockup rewards also needs to be capped. Thus, the formula applies a logarithm to the number of previous mining sessions N. For example, if a Pioneer mined almost everyday for the last 3 years, their total previous mining sessions (N) will be about 1,000. In this scenario, Log(1,000) equals 3, adding another multiplier to B in their lockup rewards. Keep in mind that to achieve meaningful lockup rewards for long-mining-history Pioneers, the amount of Pi they have to lock up is much more than smaller accounts.
Fourthly, one Pioneer can voluntarily have multiple lockups at different times with different amounts and durations. The calculation of the total lockup rewards for this Pioneer with i number of different lockups is to find the total lockcup reward multiplier of B, as expressed in the formula below. The formula below is the equivalent to the lockup reward formula above, with the only difference being that it accounts for multiple lockups of the same Pioneer to calculate their total lockup rewards, e.g. different durations (Lti) and different amounts (Lci) of each lockup at different time:
The purpose of this formula is to calculate the total lockup rewards based proportionally on each lockup’s amount (Lc) over the total Mainnet Balance from previous mining (Lb) as a weight, multiplied by their respective lockup time period (Lt) and Log(n). So that, even though there are multiple lockups of the same Pioneer, more lockups with different settings will proportionally add to their total lockup rewards. The values of Lt, Lc, and log(N) are calculated and multiplied for each lockup i and then summed across various i’s, which is then divided by the value of Lb at a given mining session, to arrive at the value of L(B) for that mining session. This formula ensures that regardless of the Lb, as long as the Pioneer maintains the same percentage of their lockup amount over their Lb, the total lockup rewards multiplier will remain the same.
Lastly, when can a Pioneer lock up Pi? Pioneers can decide their lockup duration and lockup percentage of their transferable balance anytime they want as an overall account setting in the Pi app. They can even preselect these settings before they’re KYC’ed or ready to migrate to the Mainnet. As they and their Referral Team/Security Circle pass KYC, more of their Mobile Balance will become transferable. At the moment of the migration of their Transferable Balance to Mainnet, their preselected setting of lockup duration and percentage will automatically apply to the amount of balance transferred, resulting in two types of balances on the Mainnet: lockup balance and free balance, both of which will be recorded on the Mainnet blockchain and reside in the Pioneer’s non-custodial Pi wallet. Thus, lockups cannot be reversed once confirmed and must remain locked up for the entirety of the chosen duration due to the nature of blockchain. Any changes to this Pioneer’s lockup setting will take effect in their next balance transfer to the Mainnet.
This account-wide lockup setting allows Pioneers to lock up a maximum of 100% of their transferable balance from mobile to Mainnet. After Mainnet launches and Pioneers transfer their balances, Pioneers can also lock up more Pi directly on the Mainnet through a slightly different lockup interface later on. At that time, Pioneers can lock up as much as 200% of their already-transferred Mainnet balance acquired from their previous mining. The additional lockup allowance for more Pi than individually mined by the Pioneer can come from utility-based Pi apps transactions, i.e., making Pi from selling goods and services.
App Usage Reward
An overarching goal of the Pi Network is to build an inclusive peer-to-peer economy and online experience fueled by the Pi cryptocurrency through our app ecosystem. Therefore, Pioneers will have additional mining rewards for using Pi apps on the Pi apps platform through the Pi Browser, including ecosystem apps and third-party apps in the Pi Directory. The app usage reward for Pioneers helps the ecosystem in two ways.
First, it will give Pi app developers market access and increased impressions of their apps. Pi app developers will gain usage and product iteration opportunities from Pioneers, which has been one of the biggest barriers to creating viable decentralized applications in the blockchain industry. Decentralized application (dApp) developers do not yet have a plentiful, stable, and utility-seeking consumer market environment to test and hone their consumer products to create consumer utilities. Pi Network’s apps platform and the app usage reward are meant to provide that environment for dApp developers.
Second, the increased impressions and usage will potentially lead to increased spending of Pi by Pioneers in the Pi apps, thus increasing utility-based Pi demand in the market. Even though the impressions are incentivized through the app usage reward, the spending of Pi is not. This means that the Pi app usage reward to Pioneers helps the Pi app developers to the extent that Pioneers are at their door. Now what determines whether Pioneers will actually stay and spend Pi in their apps is how useful and engaging their products are and what values the apps can provide for Pioneers. This framework ensures that, for the purpose of Pi demand creation, organic market forces are at work that allow apps to compete on the basis of product quality and utility, ultimately allowing the best apps to emerge and stay in the market and generate real utilities and even more Pi demands.
Through the above two mechanisms, the app usage reward aims to achieve the gradual transition from extrinsic incentives to intrinsic motivations among Pioneers visiting Pi apps, and thus the transition from incentivized to organic usage of Pi apps in order to ultimately bootstrap a utility-based ecosystem of apps using Pi.
The app usage reward formula is reprinted here:
A (I)* =
log [ Σ_across_apps { log(time_spent_per_app_yesterday_in_seconds) } ] • log [ log( 0.8 • avg_daily_time_across_apps_last_30_days + 0.6 • avg_daily_time_across_apps_last_90_days + 0.4 • avg_daily_time_across_apps_last_180_days + 0.2 • avg_daily_time_across_apps_last_1_year + 0.1 • avg_daily_time_across_apps_last_2_year ) ] • I
time_spent_per_app_yesterday_in_seconds is, for each Pi app, the total amount of time in seconds that the Pioneer spends using the app on the prior day.
Σ_across_apps sums up the logarithmic value of the Pioneer’s time_spent_per_app_yesterday_in_seconds across all the Pi apps.
avg_daily_time_across_apps_last_* is the average daily time in seconds the Pioneer spends across all the Pi apps in the aggregate during the last * time period.
* Note that when any of the logarithmic functions returns an undefined value or a value below 0 (that is, when, the input to the logarithmic function is below 1), the formula resets the value of the logarithmic function to be 0 in order to avoid negative mining rewards or an error in the function.
Generally, the app usage reward formula takes into account two factors: time spent in apps and the number of apps used while crediting the history of app usage in the long term and capping the rewards to avoid exploitation. There are two main parts to the formula. The first part aggregates a Pioneer’s time spent across each app in the last mining session (i.e., in the previous day). The logarithmic function provides a positive function with diminishing returns, meaning that an increase in time spent on any one app will generally increase the rewards, but the positive effect of time spent on rewards decreases as more time is spent. This setup encourages Pioneers to generally spend more time on multiple diverse apps, helping the network to bootstrap the creation of diverse utilities. At the same time, it caps the rewards to prevent users from exploiting this reward by artificially keeping the apps open all day, which would not meaningfully contribute to utilities creation.
The second part of the app usage reward formula looks at a Pioneer’s rolling average of daily time spent across all apps in various time periods. The further back the time period goes, the less it is weighted. In other words, a Pioneer mines more Pi the longer they have been using the Pi apps, but their recent time spent on the apps counts more toward mining than their previous time spent further back in the past. In addition, as a matter of fact, the app usage history takes effect on the current mining reward only if the Pioneer also used Pi apps during their last mining session. This means that there is no passive reward for only the past usage. Once again, the use of logarithmic functions helps moderate the mining boost from app usage to avoid exploitation of the app usage reward. A noteworthy implication here is that Pi chat moderators who have been helping to guide Pioneers and monitor undesirable activities on Pi chats over the last two years will mine the app usage reward at a higher rate when the Mainnet launches.
Node Reward
Like on any blockchain, Nodes are at the heart of the decentralization of Pi. In Pi, instead of relying on centralized institutional nodes, we decided to open up the Nodes to any Pioneer with a computer connected to the internet. Aided by the global trust graph aggregated from individual Pioneer’s Security Circles from the mobile app, these Nodes will run the consensus algorithm to validate transactions and process blocks. Because the Nodes are critical to the decentralization, security, and longevity of the Pi blockchain, Node-operating Pioneers will receive additional mining rewards.
The node reward formula is reprinted here:
- N(I) = node_factor • tuning_factor • I, where
Node_factor = Percent_uptime_last_1_days • (Uptime_factor + Port_open_factor + CPU_factor), where
Uptime_factor = (Percent_uptime_last_90_days + 1.5*Percent_uptime_last_360_days(360-90) + 2* Percent_uptime_last_2_years + 3*Percent_uptime_last_10_years),
Port_open_factor = 1 + percent_ports_open_last_90_days + 1.5*percent_ports_open_last_360_days + 2* percent_ports_open_last_2_years + 3*percent_ports_open_last_10_years,
CPU_factor = (1 + avg_CPU_count_last_90_days + 1.5*avg_CPU_count_last_360_days + 2* avg_CPU_count_last_2_years + 3*avg_CPU_count_last_10_years)/4.
Percent_uptime_last_*_days/years is the percentage of the last * time period when the individual Node was live and accessible by the network.
percent_ports_open_last_*_days/years is the percentage of the last * time period when the ports of the individual Node were open for connectivity to the network.
avg_CPU_count_last_*_days/years is the average CPU that the individual Node provided to the network during the last * time period. tuning_factor is a statistical factor that normalizes the node_factor to a number between 0 and 10.
The node reward depends on the uptime factor, port open factor, CPU factor, and the tuning factor. The uptime factor of a Node for a given period of time is the proportion of time the Node is active during that period. For example, a 25% uptime factor yesterday means that the Node was live and accessible for a total of 6 out of 24 hours yesterday. The Pi Node software tracks the time a particular Node is active. Starting in the Open Network phase, only a Node running functionally at a given point in time is considered active. This is a proxy for the reliability of the Node. However, for the historical data relevant to the mining reward, a Node is considered active if the Node app is open and connected to the internet even if it is not running functionally. This exemption for the past performance recognizes that the Community Node operators running the Testnet provided the network with important data and infrastructure to enable multiple iterations of the Node software and Testnet, and that it was not always the fault of the Node operator that their Nodes were inoperative.
The port open factor of a Node for a given period of time is the proportion of time the Node’s specific ports are detected to be accessible from the Internet during that period. Pi Nodes use ports 31400 through 31409, enabling other nodes to reach them through these ports and the network IP address. An open-port Node is able to respond to communications initiated by other Nodes, while closed-port Nodes are not able to receive such communications from other Nodes and can only initiate communications. Pi’s consensus protocol relies on Nodes sending a series of messages among each other. Therefore, open-port Nodes are critical to the operation of the Pi blockchain, and thus, worthy of a mining reward boost. In fact, the network aims to have at least 1/8th of the Nodes with open ports, and having an open port is one of the prerequisites for being a Super Node.
The CPU factor of a Node for a given period of time is the average number of CPU cores/threads available on the computer during that period. A higher CPU factor prepares the blockchain for future scalability, for example, the ability to process more transactions per block or more transactions per second. The Pi blockchain is not an energy and resource-intensive blockchain. The network is initially set to operate at one new block of up to 1,000 transactions (T) about every 5 seconds. Thus the network is effectively capable of processing up to about 200 transactions per second (TPS) or ~17M T/day. Should the blockchain get congested in the future, this limit can be increased to 2,000 TPS (~170M T/day) by increasing the block size from 1000 to 10,000 transactions per block. The higher the CPU contributed by Pi Nodes, the more room the network will have to grow and scale further in the future. Furthermore, higher collective CPU from Pi Nodes will allow novel peer-to-peer node-based applications to be built on Pi Network, such as decentralized CPU sharing applications that let computing power-intensive applications run or provide distributed cloud services. Such services will be further rewarding contributing nodes with additional Pi paid by the clients of those services.
Finally, a tuning factor normalizes the Node reward to a number between 0 and 10. This is meant to make Node rewards comparable to other types of mining rewards that recognize other contributions to Pi Network. During the Enclosed Mainnet phase (as explained in the Roadmap section), the Node reward formula is expected to iterate. For example, the use of logarithmic or root functions may potentially obviate the need for a tuning factor.
Having reliable Nodes running predictably over a long stretch of time is critical to the health of the blockchain. It is not a one and done contribution. Therefore, the uptime factor, port open factor, and the CPU factor are all calculated over varying time periods, where the value from more recent time periods are more heavily weighted than the time periods of equal lengths from a more distant past. Note, however, that the Node reward is a multiple of the uptime factor of the previous mining session. Hence, a Pioneer will not receive any Node reward in a given mining session if their Node was inactive for the entirety of the immediately preceding calendar day. Similar to the app usage reward, there is no passive reward for only the past contribution as a Node operator. This also means that a low uptime factor in the previous calendar day (even if the Node is active for a part of the day) will substantially reduce the Node reward in a given day despite high past Node contributions.
The Effect of KYC on Mainnet rewards
There will be a rolling grace period of six calendar months for a Pioneer to complete KYC. Thereafter, the Pioneer loses all the Pi mined outside of the rolling 6-month window and is unable to transfer the lost Pi to the Mainnet. The retention of the mined Pi in the 6-month window continues indefinitely until they pass KYC or the KYC policy changes. Note that this KYC-window mining framework will only begin when the KYC solution is generally available to all eligible Pioneers in the future, and will be announced to the community beforehand. The six-month restriction will not be immediately in place yet when we launch the Mainnet.
Because of the importance of true humanness in our social network-based mining, only the Pioneers who pass KYC will be able to transfer their Phone balance to the blockchain. Our objective is to have as many true Pioneers as possible pass KYC. As explained further below, the rolling six-month window serves the following important purposes:
- strike a balance between giving Pioneers adequate time to pass KYC and creating enough urgency to pass KYC,
- prevent unverified Pi beyond the rolling six-month KYC grace period from migrating to the Mainnet, instead freeing it up for mining by other KYC’ed Pioneers within the allocated Pi overall supply limit for Pioneer mining, and
- limit KYC spam and abuse (see 30-day delay in KYCing new members below)
If Pioneers do not pass KYC in time, it delays the Mainnet transfer of their balances and the balances of other Pioneers who have them on their Security Circles and Referral Teams. Without balances on the Mainnet, Pioneers are not able to use payments in Pi apps, thereby undermining the growth of our utility-based ecosystem. A six-month window creates a sense of urgency for Pioneers while giving them adequate time to retrieve their mined Pi. The KYC verification process will generally take into account Pioneers’ likelihood of being real human beings based on Pi’s machine-automated prediction mechanisms run over the last three years. Newly created accounts will not be able to immediately apply for KYC verification, until after 30 days. This helps the network limit the ability of bots and fake accounts to spam and abuse our KYC process and prioritize KYC validation resources for real human Pioneers.
Finally, the lost Pi of the Pioneers who delay KYC verification beyond six months will not be transferred to the Mainnet and will not be accounted for in the calculation of the systemwide base mining rate (B) beyond the rolling six-month KYC grace period. Pioneers will, therefore, need to claim their Pi in time, or their lost Pi will be reallocated to B for mining in the same year by other verified Pioneers who can make full contributions to the network.