I was reading the code and I was expecting that there should be a mechanism to halt the system when the total online stake is too low, comparing to the offline stake, but I couldn’t find that part.
How is this situation handled in the current implementation?
The code is currently using the existing online stake for the voting. As you’ve noticed, it’s undesirable by all parties that the online stake would get too low.
Your suggestion of “halting the system”, may be perceived by some as a backdoor, so one need to be careful before applying such a mechanism. Note that “halting the system” is a serious issue, since while the system is “halted”, it cannot accept new transactions and as a result, cannot support registering/revoking new/old accounts.
When an account changes its status to online will it stay online forever?
Does an account send the key registration txn only once in its lifetime?
At this time, an account that changes its status to online would remain in that state indefinitely.
An account can send key registration transaction as many times as it would like. The latest transaction is the one that applies.
So actually we already have that halting mechanism. When we don’t have enough “online” stake we will not get the 2/3 votes needed for confirming a new block and the blockchain will halt. By “online” I mean the stake that is connected to the network and is voting.
I thought that the key-registration txns were needed to be issued periodically to keep the status of an account online. The naming convention used in the code is a bit misleading. In the code “online” actually means “participating”. “offline” means “not-participating” and “not-participating” means frozen.
It is really surprising for me that in practice we always have enough online (I mean connected to the network 
) nodes to reach the 2/3 needed votes for confirming new blocks.
The ‘online’ state is bounded by the first/last range defined for the participation key though. They’re not eligible for voting. Are you saying their total is still counted though?
Yes, that’s exactly what I’m saying. The first/last rounds truly defines if an account has a valid participation key for a specific round, but that doesn’t “drop” it off the “online accounts”.
A quick query against the indexer database - breakdown by online value (offline,online,not-participating,unset)
0,32
1,437
2,85
,9190212
If I then run a query to see how many online accounts have an online participation round in range right now, it’s just 272 - so only 62% of accounts marked online are actually able to be online even if their node was running.
Obviously with such massive amounts of stake that Algorand, the Foundation and the early investors have assigned to participation nodes (each anywhere from $8 to 247 million in USD equivalent stake) it’s not an issue yet. I’ve run a node for about a year and get quite a few votes (and proposals in) and don’t have a crazy amount of stake. The system definitely works well.
As ALGO gets more distributed and as more people run nodes (almost 1800 now!) then mechanics to perhaps ‘vote’ on-chain to ‘offline’ non-participating accounts will be necessary though.
It’s always been one of the few glaring issues I’ve always seen with Algorand that I knew would have to be addressed some day.
p.s I don’t get why so few people running nodes don’t spend the extra 5 minutes and create a participation key. The 235 voters (last 7 days) is far far too low given the node counts. We need to get the word out…
Your analysis seems to align with my understanding as well. It’s definitely an area that could use some additional engineering time, but not a critical one for today.