Merge branch 'hashgraph:main' into main

HIP/hip-646.md

@@ -6,11 +6,12 @@ working-group: Michael Tinker (@tinker-michaelj), Ashe Oro (@Ashe-Oro), Michael
 type: Standards Track
 category: Service
 needs-council-approval: Yes
-status: Accepted
+status: Final
+release: v0.49.0
 last-call-date-time: 2023-01-30T07:00:00Z
 created: 2023-01-04
 discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/627
-updated: 2024-02-02
+updated: 2024-05-22
 ---
 
 ## Abstract

HIP/hip-657.md

@@ -6,11 +6,12 @@ working-group: Jason Fabritz <@bugbytesinc>, Sean Cuscus <@seancuscus>, Cooper K
 type: Standards Track
 category: Core
 needs-council-approval: Yes
-status: Accepted
+status: Final
+release: v0.49.0
 last-call-date-time: 2023-02-28T07:00:00Z
 created: 2023-01-04
 discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/607
-updated: 2024-02-02
+updated: 2024-05-22
 ---
 
 

HIP/hip-765.md

@@ -6,7 +6,8 @@ working-group: Ashe Oro (@Ashe-Oro), Michiel Mulders (@michielmulders)
 type: Standards Track
 category: Service
 needs-council-approval: Yes
-status: Accepted
+status: Final
+release: v0.49.0
 last-call-date-time: 2023-07-28T07:00:00Z
 created: 2023-07-11
 discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/pull/765

HIP/hip-850.md

@@ -0,0 +1,73 @@
+---
+hip: 850
+title: Enhancing Supply Key Functionality for NFT Updates in Treasury Account
+author: Patches (@HGraphPunks)
+type: Standards Track
+category: Core
+needs-council-approval: Yes
+status: Last Call
+last-call-date-time: 2024-06-12T07:00:00Z
+created: 2024-01-02
+discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/660
+requested-by: HGraphPunks, TierBot
+updated: 2024-05-22
+---
+
+## Abstract
+
+This HIP proposes enhancing the Supply Key functionality within the Hedera ecosystem, specifically enabling the Supply Key to update an NFT metadata field while the NFT is held in the treasury account. This ensures secure and controlled adaptability of NFTs, meeting dynamic needs while maintaining their integrity post-distribution.
+
+## Motivation
+
+Currently, there is a limitation in dynamically updating NFTs in a controlled manner. The proposed enhancement to the Supply Key functionality addresses this gap, allowing for secure and selective updates of NFTs within the treasury account, a feature particularly relevant for various evolving use cases in the Hedera ecosystem.
+
+## Rationale
+
+The enhancement focuses on granting the Supply Key the capability to update the data of an NFT serial number exclusively while it is in the treasury account. This approach ensures security and control, preventing unauthorized modifications once the NFT is distributed.
+
+## User Stories
+
+- As a stakeholder, I need the capability to update the metadata of NFTs within the treasury account to reflect the latest information, ensuring that once the NFTs are distributed, their data remains immutable.
+
+### Example Illustrations:
+- As a game developer, I want to update game piece NFTs with player stats during gameplay, ensuring the data becomes immutable once the player regains ownership.
+- As an event organizer, I need to update event ticket NFTs with attendee information while they are in the treasury account, guaranteeing data immutability post-transfer.
+
+## Specification
+
+This HIP requires an update to the Supply Key mechanism, enabling it to modify the metadata of NFTs while they are held in the treasury account. Specifically, this update introduces the capability for the Supply Key to execute the TokenUpdateNftsTransaction function, allowing for the metadata of an NFT ID to be updated while it resides in the treasury wallet. This enhancement provides a controlled method to adapt NFT metadata dynamically, ensuring that the NFT data remains immutable once distributed. This approach maintains the integrity and trust in the NFT ecosystem by preventing unauthorized modifications post-distribution.
+
+## Backwards Compatibility
+
+This proposal introduces a change in the defined capabilities of the Supply Key, which could affect the expectations of users regarding the immutability of NFT metadata. Although the Supply Key can currently burn and mint new tokens, allowing it to update metadata without burning introduces a conceptual difference. Users must be aware that the metadata of an NFT can be altered while it is in the treasury account, which can impact the perceived consistency and promises of an NFT collection.
+
+## Security Implications
+
+The primary security consideration is the prevention of unauthorized data modifications to NFTs post-distribution. The treasury account requirement for updates addresses this concern effectively. 
+
+There is no added security concern with the ability of Supply Key to adapt the metadata when in the treasury account as the Supply Key can also burn and mint new tokens. The security implications of sending a NFT to a treasury account that has a Supply Key enabled do not become worse or better with this HIP.
+
+### Modification of Previously Immutable Data
+This HIP introduces a change to the previous guarantee of immutability for NFT metadata. It is important to note that, under the new functionality, the metadata of an NFT can be updated while it resides in the treasury account. This modification capability, while restricted to the treasury account, is a departure from the guarantee of immutability that was previously assured for NFT metadata once minted. Stakeholders should be aware that this change allows for a controlled flexibility in specific circumstances, while still ensuring that the metadata becomes immutable once the NFT is distributed to end-users.
+
+## How to Teach This
+
+Educational initiatives will be developed to guide users in leveraging the new Supply Key functionality, particularly focusing on use cases like gaming and event management.
+
+## Reference Implementation
+
+The reference implementation will be comprehensive, including detailed documentation and test cases. Completion is expected prior to the HIP achieving "Final" status.
+
+## Rejected Ideas
+
+## Open Issues
+
+
+## References
+
+
+## Copyright/license
+
+This document is licensed under the Apache License, Version 2.0. See [LICENSE](https://www.apache.org/licenses/LICENSE-2.0).
+
+---

HIP/hip-869.md

@@ -11,7 +11,7 @@ status: Accepted
 last-call-date-time: 2023-02-14T07:00:00Z
 created: 2024-01-22 
 discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/pull/869
-updated: 2024-04-16
+updated: 2024-05-21
 ---
 
 ## Abstract
@@ -43,7 +43,7 @@ This HIP is focused on the HAPI Endpoints phase of the project only.   A second
 
 *Feature Benefits:*
 
-- Enables Hedera and node operators to manage address book without Swirlds Labs involvement.
+- Enables Hedera council and node operators to manage address book automatically.
 - Core building block to support eventual support for community and permissionless nodes.
 - Enables the rotation of node operators off the Hedera network should it be required as contracts expire.
 - NMT integration of local node firewall admin reduces cost & complexity of node operations.
@@ -58,63 +58,44 @@ Adopting a two-phase strategy, this approach facilitated the earlier release of
 
 **Personas**
 
-**Council Member** - A member of the council authorized to submit address book changes
+**Council** -  Hedera Council 
 
-**Node Operator** - Technical administrator of Hedera Consensus Nodes
+**Node Operator** - Administrator of Hedera Consensus Nodes
 
-**Add Node to Address Book**
 
-***User Story:*** As a council member, I want the ability to submit signed HAPI transactions to add a new consensus node to the Hedera network upon the next maintenance window, so that I can perform operations independently.
+***User Stories:*** 
+1. As the Council, we want to submit signed HAPI transactions to add a new consensus node to the Hedera network upon the next maintenance window, so that management of Hedera's Address book is automated.
 
-***Acceptance:*** When a valid council member initiates a HAPI transaction to add a new node, then the network should acknowledge the transaction and perform an update to the network’s Address Book at the next maintenance window.
+*Acceptance: When the council initiates a HAPI transaction to add a new node, then the network acknowledges the transaction and performs the update to the network’s Address Book at the next maintenance window.*
 
-**Remove Node from Address Book**
+2. As the Council, we want to submit signed HAPI transactions to remove a consensus node from the Hedera network upon the next maintenance window, so that management of Hedera's Address book is automated.
 
-***User Story:*** As a council member, I want the ability to submit signed HAPI transactions to remove a new consensus node to the Hedera network upon the next maintance window, so that I can perform operations independently.
+*Acceptance: When the council submits a HAPI transaction to remove a node, then the network should acknowledge the transaction and performs the update to the network’s Address Book at the next maintenance window.*
 
-***Acceptance:*** When a council member submits a HAPI transaction to remove a node, then the network should acknowledge the transaction and perform an update to the network’s Address Book at the next maintenance window.
+3. As a Node Operator, I want to submit a signed HAPI transaction that modifies one or both of an existing node's IP addresses and/or ports, so I can independently perform address book related node operations.
 
-**Update Node IP Address(s) and Port(s)**
+*Acceptance: When a Node Operator submits a HAPI transaction to modify a node's primary IP address:port or secondary IP address:port, the network acknowledges the transaction and performs the update to the network’s Address Book at the next maintenance window.*
 
-***User Story:*** As a council member, I value the ability to submit a signed HAPI transaction that modifies one or both of an existing node's IP addresses and/or ports.
+4. As a Node Operator, I want to submit a signed HAPI transaction that modifies a list of GRPC proxy endpoints supporting both IP and FQDN address formats, so I can independently perform address book related node operations.
 
-***Acceptance:*** When a council member submits a HAPI transaction to modify a node's primary IP address:port or secondary IP address:port, network should acknowledge the transaction and perform an update to the network’s Address Book at the next maintenance window.
+*Acceptance: When a Node Operator submits a HAPI transaction to modify a node's IP address:port or FQDN:port, the network acknowledges the transaction and performs the update to the network’s Address Book at the next maintenance window.*
 
-**Update GRPC Proxy Endpoint(s)**
+5. As a Node Operator, I want to submit a signed HAPI transaction that modifies a node’s description within the Address Book, so I can independently perform address book related node operations.
 
-***User Story:*** As a council member, I value the ability to submit a signed HAPI transaction that modifies a list of GRPC proxy endpoints supporting both IP and FQDN address formats.
+*Acceptance: When a Node Operator submits a HAPI transaction to modify a node's associated Description Field, then the network acknowledges the transaction and performs the update to the network’s Address Book at the next maintenance window.*
 
-***Acceptance:*** When a council member submits a HAPI transaction to modify a node's IP address:port or FQDN:port, then network should acknowledge the transaction and perform an update to the network’s Address Book at the next maintenance window.
+6. As a Node Operator, I want to submit a signed HAPI transaction that modifies a node’s public key within the Address Book used for signing, so I can independently perform address book related node operations.
 
-**Update Node Description**
+*Acceptance: When a Node Operator submits a HAPI transaction to modify a node's associated Public Key, then the network acknowledges the transaction and performs the update the network’s Address Book at the next maintenance window.*
 
-***User Story:*** As a council member, I value the ability to submit a signed HAPI transaction that modifies a node’s description within the Address Book.
+7. As a Node Operator, I want to submit a signed HAPI transaction that modifies a node’s Account ID within the Address Book, so I can independently perform address book related node operations.
 
-***Acceptance:*** When a council member submits a HAPI transaction to modify a node's associated Description Field, then the network should acknowledge the transaction and perform an update to the network’s Address Book at the next maintenance window.
+*Acceptance: When a Node Operator submits a HAPI transaction to modify a node's Account ID, then the network acknowledges the transaction and performs the update the network’s Address Book at the next maintenance window.*
 
-**Update Node’s Public Key**
+8. As a Node Operator, I want to submit a signed HAPI transaction that modifies a node’s X509 certificate hash within the Address Book, so I can independently perform address book related node operations.
 
-***User Story:*** As a council member, I value the ability to submit a signed HAPI transaction that modifies a node’s public key within the Address Book used for signing.
+*Acceptance: When a Node Operator submits a HAPI transaction to modify a node's associated X509 certificate hash, then the network acknowledges the transaction and performs the update the network’s Address Book at the next maintenance window.*
 
-***Acceptance:*** When a council member submits a HAPI transaction to modify a node's associated Public Key, then the network should acknowledge the transaction and perform update the network’s Address Book at the next maintenance window.
-
-**Update Node’s Account ID**
-
-***User Story:*** As a council member, I value the ability to submit a signed HAPI transaction that modifies a node’s Account ID within the Address Book.
-
-***Acceptance:*** When a council member submits a HAPI transaction to modify a node's Account ID, then the network should acknowledge the transaction and perform update the network’s Address Book at the next maintenance window.
-
-**Update Node’s X509 Certificate**
-
-***User Story:*** As a council member, I value the ability to submit a signed HAPI transaction that modifies a node’s X509 certificate hash within the Address Book.
-
-***Acceptance:*** When a council member submits a HAPI transaction to modify a node's associated X509 certificate hash, then the network should acknowledge the transaction and perform update the network’s Address Book at the next maintenance window.
-
-**Automated Firewall Adaptation**
-
-***User Story:*** As a node operator, I rely on the Network Management Tool (NMT) to automatically adjust firewall configurations based on transactions associated with address book changes, so that I can perform operations independently.
-
-***Acceptance:*** When a HAPI transaction triggers an address book change involving a node's addition or removal, or IP:Port change, then the network should acknowledge the transaction and perform update the network’s Address Book at the next maintenance window.
 ## Specification
 
 This HIP proposes the introduction of a new NodeService API that enables a node operator to create, delete, and update nodes. All of these transactions must be signed by the Hedera Council.
@@ -341,7 +322,7 @@ Each transaction made through NodeService will have a corresponding transaction
 
 During stage1, node changes will not be active until the network is upgraded. When the node starts, the Platform still uses config.txt to create an AddressBook, which is then passed to Services. This AddressBook contains the activated nodes in the network. Services use the activated nodes to calculate weight.
 
-During the *PREPARE_UPGRADE* freeze period, Services will generate a new config.txt and public.pfx file based on all the NodeService transactions since the last upgrade. These two files will be added to the location where file 0.0.150 is unzipped. Once the *FREEZE_UPGRADE* is completed, the freeze_scheduled.mf mark file is generated. This file will trigger DevOp to run NMT.## Backwards Compatibility
+When executing the next `freeze` transaction with `freeze_type` set to `PREPARE_UPGRADE`, services will update network configuration according to the pending modifications for all node create, update, or delete transactions since the last upgrade and merge any pending state to active state.
 
 All HIPs that introduce backward incompatibilities must include a section describing these incompatibilities and their severity. The HIP must explain how the author proposes to deal with these incompatibilities. HIP submissions without a sufficient backward compatibility treatise may be rejected outright.