HIP-1299 account_id updates for Address Book Node Entries.

[jsync-swirlds]

Description

This proposal refines the rules for managing the account ID associated with
Node entries in the Dynamic Address Book (DAB). The DAB is a feature that
stores information about network nodes, such as their identifiers and associated
accounts, directly in the network's state instead of in Hedera File Service (
HFS) files. This makes updates more secure and consistent.

The refinements focus on how account IDs can be updated, removed, or set, with
an emphasis on security through required signatures, preventing reuse of the
same account ID across multiple nodes, and handling cases where accounts lack
sufficient funds. These changes provide flexibility for node operators while
protecting the network from disruptions.

[steven-sheehy]

LGTM

[akdev]

LGTM

[Reccetech]

I think this HIP would benefit from some user stories around the node account ID updates. i.e. why a node operator would want to change their Account Node ID.
@Mark-Swirlds

[popowycz]

A few comments:

1. The use of node account ID as the "primary key" should be addressed in conjunction with this to provide a more constant pointer for submitting transactions, as node account ID changes will likely be more volatile than node IDs. This doesn't suggest that such a HIP needs to be finalized prior to this HIP, only that directionally the change to using Node ID for transactions is forthcoming as part of the roadmap, giving further notice to the community that might be affected by these changes.
2. I don't want to include limitation the restricts an account from being associated with a given node. In the short term this must be addressed to ensure deconfliction pending changes to the use of Node ID vs Node Account ID down the road, but there are relevant use cases (perhaps corner cases) for having a many to one account to node mapping. However, this is not a hard blocker for me given some of the internal complexities associated.
3. Node accounts must have an override to certain attributes such as "receiver signature required" for synthetic transactions or transactions submissions to ensure that regardless how that is set for an account, that node fees (similar to what is described for node rewards in the HIP to the extent I am interpreting how that's described).
4. Regarding node account deletion restrictions, I would like to see the HIP address situations where negative actions that could affect a node account (and hence the availability of the node itself) are addressed programmatically to the extent practicable. For example, implementing the ability to set minimum balances for node accounts to prevent user-initiated withdrawals that go below a configured threshold (e.g. 5 HBAR on the Hedera network) should be considered. Perhaps even making node accounts "rent free" to remove the risk of node suspension/deletion for that reason.
5. I'm unclear as to the purpose for removing an account ID (vs replacing/updating the ID).
6. Under "How to Teach This" is the situation where a node does not have a node admin key? I don't understand how the description to update the node account without a node admin key would be executed (...sign with the old and new accounts).
7. Nit - there is reference at the end of the HIP to "Hedera API (HAPI)" - should that be "Hiero API (HAPI)"?
8. I believe there is a configuration flag to enable or disable the ability to change node accounts. If correct, I think that should be referenced in this HIP.
9. There is a discrepancy with HIP-869 - in User Story 7 Modify Node's Account ID, where such a change only requires that the node admin key sign the update, in contrast to this HIP which specifies that such a change requires both the node admin key and the account admin key. If the latter, we should update HIP-869. Personally, I think the requirement for the node account to be a signatory to the update transaction is useful to validate control of the node account and that the node account owner is approving the receipt of node fees/node rewards, etc.

[jsync-swirlds]

Some partial responses, numbered to match.
(1) This is definitely on the roadmap and a HIP regarding this change will begin detail work in the near future. There is a high level of complexity involved, so actual time of publication is not yet known.
(5) Removing an account ID is a mechanism to protect the account holder if different from the node operator. This change (removing the account ID) only requires the signature of the account holder, and enables that account holder to remove themselves from a node, even if that node operator is not available or not willing to make that change.
(6) This isn't a missing node_admin key, it is a case where the holder of the node_admin key is either unavailable or unwilling to change the account, but the account owner, for whatever reason (change of control, account management, compromise, etc...) needs to change the account ID assigned to the node.
(7) Yes, we need to make that change.
(8) We can add that reference
(9) This HIP supersedes HIP-869 with regard to the signing requirement for these updates. I'm not sure if we need to update that HIP, or only acknowledge that later HIPs can (and do) change the implementation relative to earlier HIPs.

[rbair23]

@popowycz:

I don't want to include limitation the restricts an account from being associated with a given node. In the short term this must be addressed to ensure deconfliction pending changes to the use of Node ID vs Node Account ID down the road, but there are relevant use cases (perhaps corner cases) for having a many to one account to node mapping. However, this is not a hard blocker for me given some of the internal complexities associated.

My recommendation is we roll this forward into a new HIP so we don't delay the implementation of this one. I hear you from the user story perspective, and other than the effort in testing and implementation this seems like a reasonable request. Yes, it is dangerous if all council members have the same account (and this has overlap with your point #4). Given that additional complexity, I think we should consider this and point 4 together in a subsequent HIP.

Node accounts must have an override to certain attributes such as "receiver signature required" for synthetic transactions or transactions submissions to ensure that regardless how that is set for an account, that node fees (similar to what is described for node rewards in the HIP to the extent I am interpreting how that's described).

Agreed. Neither receiverSigRequired nor hooks nor rain nor sleet should stop us from delivering fees / rewards into the account. It is exactly the same concept as staking rewards -- an account will receive staking rewards without regard to hooks or receiverSigRequired etc.

Regarding node account deletion restrictions, I would like to see the HIP address situations where negative actions that could affect a node account (and hence the availability of the node itself) are addressed programmatically to the extent practicable. For example, implementing the ability to set minimum balances for node accounts to prevent user-initiated withdrawals that go below a configured threshold (e.g. 5 HBAR on the Hedera network) should be considered. Perhaps even making node accounts "rent free" to remove the risk of node suspension/deletion for that reason.

I really like these ideas. For example, we can say that for each node an account will be the account for has to hold 1M hbars (just picking the number out of the air). So if an account is the account for 10 nodes, it has to hold 10M hbars. And we make it so that the account holder cannot move funds out below this threshold. The only way it dips below this number is if the account has to pay penalties. In some way it is like "graceful slashing" -- if the node account does something wrong it doesn't immediately lose all locked funds, but it loses proportional to the "bad" it did. The funds are released when the account is no longer the account for the node.

Since the account can remove itself from the node, a bad node cannot hurt the node account unfairly (i.e. if the node account says "I don't like you anymore" it can remove itself). And the node stops being a node if the account goes way.

I really like this idea and it helps make sure there are funds to pay for penalties long before we actually get to zero. And we could also say there is another threshold, like 10K hbars, where if you dip below that number then we automatically remove the node from the roster. This means we still have enough in the account to continue paying for penalties until we can actually remove the node.

Let's roll this idea forward into a new HIP so we can make progress on this one. But I really like these ideas. Rent free maybe or maybe not, if we have these other threshold requirements, then we don't really have a risk of rent running out. So I think we can probably not do the rent free idea.