Very good questions, Jordan.
The simple truth is that this is the high-level vision, many nitty-gritty details need to be worked out together with the community to make it a reality. The original version of this post was 5x longer, but we opted for simplicity and more dialogue rather than producing tomes, so I am not surprised there are questions.
We have been considering these issues, haven’t written much about them yet (will be tackled in different motion proposals we are working on).
What I consider to be more baked:
- Locking some amount of ICP is one of the mechanisms we’re considering to incentivize node providers, and the hardware is actually of non-negligible cost, so you can view this as staking as well.
- We are working on Trusted execution enhanced nodes, incl remote attestation, there will be a separate motion proposal on it (and update coming this week). See: AMD SEV Virtual Machine Support and more coming soon.
What I expect will iterate more through community feedback:
- I expect the AMOUNT of ICP to be something that is calibrated and goes through community discussions.
- Different models for node operator remuneration mechanisms have been discussed internally (pros and cons) and we will be bringing them up openly to discuss.
Slow roll-out of phase 2
To gain some experience with the new deployment approach and to course-correct before the “flood gates” are opened, as you write, the rollout of phase 2 starts slowly. That is also indicated in the timeline visualization.
At the risk of being redundant, I will address your questions directly:
- How will we ensure that node operators are incentivized to be honest?
Mid-term, the IC shall be able to detect abnormal participation in the consensus algorithm. In a first step, remuneration for such nodes can be reduced and ultimately the IC might create proposals to replace such nodes. We will not have full automation for all of this ready on day 1, but we are confident to get there over time.
- And how will we verify their honesty?
The consensus team is better equipped to give a sound answer, my try: as long as not more than a third of the nodes in a subnet act maliciously or faulty, it’s possible to identify such nodes: for example, they do not contribute to the notarization of blocks or abstain from contributing to the random beacon.
- Is there any type of staking?
Yes, the team’s current thinking is that staking can help line up incentives.
- Can we force secure enclave attestations of the replica, combining it with consensus, so that we can verify the replica has not been modified?
Yes, this is a project on its way and we will update this week hopefully.
- Should we look into more automatic ways of compensating node operators? A fixed fee determined by vote seems much more subject to manipulation than a fee model that pays node operators in cycles, in addition to burning cycles.
Definitely, something we want to engage in discussion on. I will let Luis, Yvonne-Anne, Sam give some more context