Proof-of-Utility — the only consensus mechanism for scalable blockchain protocols

Previously we read about Proof of Work (PoW) and Proof of Stake (PoS), two commonly used consensus mechanisms. However, both mechanisms, along with their delegated counterparts (i.e. DPoS) still present themselves as energy-intensive and inefficient mechanisms that are not ideally suited for scalable blockchain protocols. Furthermore, in the vast majority of systems, dishonest behaviors are not explicitly penalized by the protocol rules themselves.

Jura’s Proof of Utility Consensus Mechanism

In a P2P network, a consensus mechanism would ideally incentivize honest nodes and prevent dishonest nodes from performing malicious activities. To achieve a near-idea consensus mechanism, JURA designed the Proof of Utility (PoU) mechanism, which is inspired by your typical credit rating system, as well as the coin-age concept originally proposed by Peercoin. The main idea here is that we need a system to regulate voting, as well as to penalize dishonest voting behavior. So we thought to ourselves: instead of using just one metric such as stake size or computing power to assess the voting power of a user, why not:

— Use multiple variables, so we have a better idea of how trustworthy a user actually is? Some variables might present themselves as better distinguishing factors than others, so why not also…

— Have variable weights that change over timeso no one user can game the system? This evolution over time can follow system demographics and PoU scores. That is, if variable A becomes a more distinguishing factor in the system compared to variable B, A’s weight will increase and B’s will decrease. But this could still lead to users gaming their PoU scores, so why not also…

— Make variables non-linearly distributed? For example, a user with a 10x score increase in variable A won’t have 10x more voting power than another user with a system average score in variable A, provided their scores for all other variables were identical. To get around this, all variable scores are distributed between 0 and 1 via a Gaussian distribution function.

Note that variable parameterization and the subsequent calculation of a user’s PoU score is a very straightforward operation and will not impose significant latencies to the system. The natural question that comes next is what are the variables we’re talking about? Although this can vary from system to system, our initial model has four main variables:

1. Stake size
   Simply, the total amount that the user has entered into the system. All accounts must have a non-zero balance to partake in voting, so Sybil-type attacks will be economically unfeasible.
2. Cumulative stake time (CST)
   This basically denotes seniority: the total time that a node has spent on the system, defined as the time between the first stake to the current time. Keep in mind that as more users join the system, early adopters of JURA will have an increasing, but marginal, advantage over new users. This ensures that new stakes won’t be able to immediately influence the system and make rushed or blitz-type malicious attacks impractical. This idea of interacting stakes with age resonates with the democratic voting system where although every person has one vote; senior members of greater expertise and a larger network tend to have more influence.
3. Average interstaking time (AIST)
   AIST is a measure of the time between multiple consecutive stakes — the lower your AIST, the higher your rate of participation. As nodes participate more often, but honestly, their PoU scores will increase. Our inclusion of AIST in this case is mostly concerned with long-term behavior, because as time masses, the habitual behavior of accounts emerge and converge to show a discerning pattern with overlapping parameters. Including AIST in the consensus mechanism also prevents stakes with high CST but insufficient activity levels to have a large influence in the consensus mechanism.
4. Last interstaking time (LIST)
   Finally, LIST is the timestamp of the last staked activity in the system. Similar to AIST, a smaller LIST value indicates higher participation rates, but focuses more on short-term activity. The marginal weight of 1-T(t1) thus acts as a buffer for large stakes with active participation but haven’t been active on the system recently.

All of this information can be derived from transactions and system information and together, PoU gets us a more holistic system-level of user trustworthiness. We purposely designed this to be customizable to different industries and applications, so in our protocol, only a minimal number of values are hardcoded.

Most importantly however, users cannot game the system since the weights associated with each of the variables evolve over time: as the system demographics change, so do the weights. The adjustment of system-wide PoU weights and calculation of individual PoU scores, which will happen at regular customizable intervals, won’t take much considerable computing power at all, but will serve to provide a lightweight, effective framework for ensuring a fair consensus. For our initial model, PoU scores are calculated on the order of days.

The margin distribution is then two dimensional multi-gaussian and the POU score is corresponding CDF. The demo samples full nodes with 4 features independently follow gaussian distribution and based on the resulting empirical distribution, the POU is calculated empirically. Note that the behavior looks a lot like CDF of multi-gaussian which is our expectation

Finally, for those of you who may be mathematically inclined, please see our white paper for a more detailed and theory-based mathematical description at https://jura.network. Happy reading!

— The JURA Team

Official homepage — https://jura.network
Official English Telegram — https://t.me/juranetwork
Telegram ANN channel — https://t.me/juranetworkann
Official Twitter — https://twitter.com/JuraProtocol
Official Medium — https://medium.com/@juraprotocol
Official Vietnam Telegram — https://t.me/JuraVietnam 🇻🇳
Official Korea Telegram — https://t.me/jurakoreangroup 🇰🇷