Skip to content
Snippets Groups Projects

Fix Deep Dive WoT article

Merged Fix Deep Dive WoT article
LukeMarlin/website_en:deep-dive-wot-fixes into master
Merged Luke Marlin requested to merge LukeMarlin/website_en:deep-dive-wot-fixes into master
Compare
and
1 file
+ 7
− 8
Compare changes
  • Side-by-side
  • Inline
content/2018-06-18-duniter-deep-dive-wot.md
+ 7
− 8
@@ -128,11 +128,11 @@ The Duniter WoTs -one per currency- work with a set of eight fundamental rules,
Let’s now define the distance rule:
> **Distance rule**: member A is said to observe this rule if and only if for a subset xPercent % of referent members R there exists a path of length less than or equal to `stepMax` between R and A.**
> **Distance rule**: member A is said to observe this rule if and only if for a subset `xPercent`% of referent members R there exists a path of length less than or equal to `stepMax` between R and A.**
Referent members only exist so that the distance rule can take effect, they have no special privileges over non-referent members.
In a perfect web, that is one in which each member has certified all members he/she legitimately can, all members would be referent members. However, because the web progressively grows in size and because members die and are replaced by new ones, there are always members at any given time `t` who haven’t yet certified all members they legitimately could. These members would hinder the evolution of the web if they were taken into account in the calculation of the distance rule and the web would effectively stop growing.
-You can see what would happen if the notion of ‘referent member’ didn’t exist by going to the ‘gaussianWotQuality’ page on [currency-monit](https://g1-monit.librelois.fr/gaussianWotQuality?lg=en&unit=quality) and activating ‘if the concept of referent members didn’t exist’-.
-You can see what would happen if the notion of ‘referent member’ didn’t exist by going to the ‘gaussianWotQuality’ page on [currency-monit](https://monit.g1.nordstrom.duniter.org/gaussianWotQuality?lg=en&unit=quality) and activating ‘if the concept of referent members didn’t exist’-.
> **When is the distance rule applied?**
@@ -153,13 +153,13 @@ Every single member -or old member who hasn’t revoked his identity or been exc
A new request will be stored in the ‘pool’ for a maximum of `msWindow` seconds before it’s included in the blockchain. Once again, this can only happen once/if the member meets both the `siqQty` rule and the distance rule -if these criterion are already matched it’s just a case of waiting for a new block to be mined-.
If a member hasn’t requested a renewal for longer than `msValidity` seconds, he/she automatically ceases being a member. From this moment on, the ex-member has another `msValidity` window to renew his/her membership.
When this period of `2 × msValidity’ runs out, the membership will expire and this identity will never be available for use again in the web. If the person so desires, he/she will have to start from zero to regain access to the WoT.
When this period of `2 × msValidity` runs out, the membership will expire and this identity will never be available for use again in the web. If the person so desires, he/she will have to start from zero to regain access to the WoT.
## 4. Rule of certification lifespan (`sigValidity`)
All certifications included in the blockchain expire **sigValidity** seconds after they were **issued**.
All certifications included in the blockchain expire `sigValidity` seconds after they were **issued**.
/!\ The issuance and the inclusion of a certification in the blockchain occur at different times. When member A issues a certification at time t1, it gets stored in the pool starting at t1 and only finds its way into the blockchain at t2 when all of the web’s rules are observed. Several weeks can thus go by between t1 and t2!!!
/!\ The issuance and the inclusion of a certification in the blockchain occur at different times. When member A issues a certification at time _t1_, it gets stored in the pool starting at _t1_ and only finds its way into the blockchain at _t2_ when all of the web’s rules are observed. Several weeks can thus go by between _t1_ and _t2_!
## 5. Rule of limited supply of active certifications (`sigStock`)
@@ -167,7 +167,6 @@ By ‘active certifications’ we refer to certifications included in the blockc
The total of active certifications issued by any member at any single time must be less than or equal to `sigStock`. When this threshold is reached the member will have to wait for one of his active certifications to expire before he/she can issue a new one.
## 6. Rule of the time period between two certification issuances. (`sigPeriod`)
As soon as a certification issued by member A gets included in the blockchain, he/she will be unable to issue a new one before another `sigPeriod` seconds.
@@ -247,7 +246,7 @@ In addition, the higher `sigPeriod` is, the more members will exercise their cer
There are numerous advantages to giving `sigPeriod` a high value and no technical barriers to it, hence our choice of five days.
We could have also gone for days days -one week- for the sake of simplicity however there was an underlying idea behind our choice which was quite simply the pace of today’s life.
We could have also gone for seven days -one week- for the sake of simplicity however there was an underlying idea behind our choice which was quite simply the pace of today’s life.
Certifying someone can be a lengthy process as one needs to make sure he/she is correctly applying the Ğ1 licence and people nowadays wait for the weekend to enjoy a bit of free-time. Thus the idea to allow one to certify at the end of every working week -five days- instead of a whole calendar one.
## 3. Trust me now, trust me forever? (`sigValidity`, `msValidity`)
@@ -260,7 +259,7 @@ To achieve this, certifications have a limited lifetime and members need to seek
Furthermore, a certification with too short a lifetime would foster careless certifying behaviours. The act of certifying must have a ‘perceived’ cost high-enough to make it feel like an important act.
Lastly, we also wanted this lifetime to be easy enough to remember.
Historically speaking, we first settled on the values of
`sigPeriod` and `sigStock`, meant one could issue all of his/her certifications in 495 days, one year was therefore not long enough. We deemed three years to bee much and that’s how we agreed on two years in the end.
`sigPeriod` and `sigStock`, meant one could issue all of his/her certifications in 495 days, one year was therefore not long enough. We deemed three years to be too much and that’s how we agreed on two years in the end.
Thinking that a deceased member could continue producing the UD for two long years without anyone benefitting from it was also something we needed to address.
We choose a value of one year for **msValidity**. The act of renewing every year is done through one of the clients interacting with the blockchain, through a simple click on a button.