RECAP - March PRV Holders Call

[aaron]

Water, air, glass, and pellucid single-crystal aluminum oxide.

What do these things have in common?

Transparency!

That also happened to be a focus of this month’s PRV Holders Call. We shared plans to refocus on transparency and decentralization before continuing to build shiny new products. The privacy movement is growing quickly, and now that we’ve got plenty of tools that we can use to protect ourselves, it’s important to decentralize them all. All along the way, we’re going to be publishing new documents and other resources explaining the project in greater detail, which will make it even easier for anyone to participate in building privacy.

Hear more on that, as well as see recent growth and get answers to community-asked questions in the recording below:

Subscribe to Incognito on YouTube and LBRY for more.

Highlights

Intro - 6:00

Presentation intro - 6:05

Shielding transaction volume - 7:00

Shielding volume - 7:47

Trading volume - 8:24

Liquidity - 9:09

Key development intro - 9:45

Dynamic committee size - 10:44

Privacy v.2 - 11:39

Portal - 12:47

Ledger & gas optimization - 13:58

App v.5 - 14:55

Research - 17:26

Growth efforts - 19:10

Builder Rewards - 21:15

@Andrey on nodes, transparency, & decentralization - 22:05

Q&A - 33:08

Closing thoughts - 1:01:40

What did you think?

Share your thoughts and questions here, and get ready for the announcement of the next PRV Holders Call - we’d love to see you there.

[sjo114]

Considering that the physical nodes are made by Incognito and not by users, I’m not thrilled about the way that slashing is being approached. Myself and a friend both stake our own PRV for our nodes, but now we will likely switch back to community staking. The risk of our PRV being slashed out of error and the headache it will cause, however unlikely, is not worth the capital risk anymore.

Power outages happen. We’re retail individuals, not industry cloud service providers. Also, every time after Earning, the node status always shows Offline. The inconsistency of the Node Status is also not worth the stress. Slashing should only be for attempted malicious attacks on the network, which should be trustlessly verified by the other nodes on the network and not by the Incognito team. For reference, RenVM does this community slashing well for its darknodes.

If you’re going to implement slashing, you need to do several things first.

1. Give plenty of runway time for validators to unstake their own PRV.
2. Explicit dates for when it begins.
3. Explicit conditions for what constitutes slashing.
4. Slashing has to be determined by the nodes, not by the team.

So far, the first I heard about this was because I happened to listen to the section of this call around 30:00 where @andrey says it’s happening within 2 months. You need to do a much better job of announcing this to the community.

[Tempestblack]

Very much I agree with @sjo114…and mind you I have pnodes and not vnodes…but this slashing issue does raise issues that sjo114 speaks on in his post…

[key]

I too am frustrated by the “Offline” status not functioning with accuracy. It stresses me out already, that the node might be disconnected from network. It is frustrating today with no active threat of slashing!

@aaron thank you for facilitating the call. I look forward to reviewing it on LBRY.

[Jamie]

Slashing has been talked about for a long time now. It was mentioned how it was not in place yet, and how it would be added later on. You kind of make it sound like it was hidden, it was not.

That said, there absolutely needs to be a better, more accurate way to know about the node status before this feature is implemented.

[17Strife]

Is the risk with slashing that a fully self-funded pNODE could be kicked out of the selection process and the user also loses the stakes 1,750 PRV?

If so, there should be some form of Notice of Intent to Slash provided to the user. If they are advised in advance that their pNODE is not functioning appropriately and is under consideration for slashing, then the user should be allowed to un-stake their pNODE.

Otherwise, many users would be afraid to self fund a pNODE, only to find out that it wasn’t working well and lose their 1,750 PRV.

[duc]

guys, let me clarify a bit to help people understand correctly about slashing and what steps both the core team and node owners need to do in order to move towards its goal - “healthy” validators help verify the honesty of blocks producing by block proposer:

1. Improving node statues with more comprehensive info so that node owners can understand whether their nodes are operating well as expected or not.
2. The core team will help node owners solve issues if any.
3. Then we can make decision to enable slashing.
4. The core team will also collect data to see how nodes/validators contribute to the network prior to and after slashing. Are they contributing well to the network’s block creation/validation besides the currently fixed nodes?
5. Once we have more insights into this, we’ll be able to figure out the approach to release the fixed nodes.

Regarding slashing, basically, it’s based on the number of blocks a validator/node participating in block validation in an epoch when the node/validator is in a shard committee. If the node/validator misses more than x% (say x = 25) of number of an epoch’s blocks (350) for any reasons (connection issue, power outage, etc) then the node would get slashed. And for slashing’s punishment, it’s not too extreme, the node will be kicked out of the committee and forced to unstake at the end of the epoch. The node owner can totally re-stake again after he fixes his node’s issues.

Again, the core team DOES NOT slash your node but the network (the code rule for more correctly). And once your node gets slashed, you can receive back your full 1750 prv, it is not taken from you.