From c418a1612077486236b14feb5f94e9d0a06bbf31 Mon Sep 17 00:00:00 2001 From: Michael Garber Date: Mon, 13 May 2024 07:49:57 -0400 Subject: [PATCH] Change validator terms (#963) Signed-off-by: Michael Garber --- HIP/hip-1.md | 4 +- HIP/hip-11.md | 10 +-- HIP/hip-13.md | 4 +- HIP/hip-171.md | 2 +- HIP/hip-173.md | 16 ++--- HIP/hip-179.md | 6 +- HIP/hip-18.md | 2 +- HIP/hip-206.md | 2 +- HIP/hip-28.md | 2 +- HIP/hip-367.md | 4 +- HIP/hip-406.md | 2 +- HIP/hip-410.md | 8 +-- HIP/hip-534.md | 157 +++++++++++++++++++++++++++++++++++++++++ HIP/hip-631.md | 2 +- HIP/hip-639.md | 2 +- HIP/hip-791.md | 182 ++++++++++++++++++++++++++++++++++++++++++++++++ HIP/hip-796.md | 2 +- HIP/hip-830.md | 4 +- HIP/hip-867.md | 2 +- about-hips.html | 2 +- 20 files changed, 377 insertions(+), 38 deletions(-) create mode 100644 HIP/hip-534.md create mode 100644 HIP/hip-791.md diff --git a/HIP/hip-1.md b/HIP/hip-1.md index d93d1a351..78386f6c9 100644 --- a/HIP/hip-1.md +++ b/HIP/hip-1.md @@ -32,7 +32,7 @@ There are three kinds of HIP: **c. Mirror:** A mirror node runs software designed to retrieve all, or some of the records generated by the Hedera consensus nodes and make those records available to users in a way that is meaningful, reliable, and trustworthy. - **d. Application:** Application standards may be used to standardize software in the Hedera ecosystem that aren't mirror or consensus nodes. This includes application network software, external contract validators, multi-sig oracles, persistence mechanisms, enterprise software plugins, etc. An example of an Application standard would be the Stablecoin Contract and Non-fungible Token Contract written in Java as a layer-2 solution using the Hedera Consensus service to maintain trust. + **d. Application:** Application standards may be used to standardize software in the Hedera ecosystem that aren't mirror or consensus nodes. This includes application network software, external contract consensus nodes, multi-sig oracles, persistence mechanisms, enterprise software plugins, etc. An example of an Application standard would be the Stablecoin Contract and Non-fungible Token Contract written in Java as a layer-2 solution using the Hedera Consensus service to maintain trust. 2. An **Informational** HIP describes a Hedera design issue or provides general guidelines or information to the Hedera community but does not propose a new feature. Informational HIPs do not necessarily represent a Hedera community consensus or recommendation, so users and implementers are free to ignore Informational HIPs or follow their directions. @@ -162,7 +162,7 @@ The possible paths of the status of HIPs are as follows: - __Idea__ - An idea that is pre-draft. This is not tracked within the HIP Repository. - __Draft__ - The first formally tracked stage of a HIP in development. A HIP is merged by a HIP Editor into the HIP repository when properly formatted. - __Review__ - A HIP Author marks a HIP as ready for and requesting Editorial Review. -- __Deferred__ - A HIP that is already being addressed in another HIP +- __Deferred__ - A HIP under consideration for future implementation, but not set for immediate action. - __Withdrawn__ - The HIP Author(s) have withdrawn the proposed HIP. This state has finality and can no longer be resurrected using this HIP number. If the idea is pursued at a later date - it is considered a new proposal. - __Stagnant__ - Any HIP in Draft or Review if inactive for a period of 6 months or greater, is moved to Stagnant. A HIP may be resurrected from this state by Authors or HIP Editors through moving it back to Draft. - __Rejected__ - Throughout the discussion of a HIP, various ideas will be proposed which are not accepted. Those rejected ideas should be recorded along with the reasoning as to why they were rejected. This helps record the thought process behind the final version of the HIP and prevents people from bringing up the same rejected idea again in subsequent discussions. diff --git a/HIP/hip-11.md b/HIP/hip-11.md index 333030954..4ff2621af 100644 --- a/HIP/hip-11.md +++ b/HIP/hip-11.md @@ -84,18 +84,18 @@ Source code of the standard Ethereum full node (e.g. geth node) is forked and mo . Reading of the balances of other accounts: the layer-2 node could listen to the mirror node transaction records to find out the balances, and calculate the balances accordingly. We could modify the `BALANCE` opcode of the EVM to fetch this information from a mirror node. ### Properties of this solution -* Trust: End-users can trust this system as long as they can trust a configured number of community validators is honest. -* Transparency: All validator signatures can be verified through the record of the scheduled transactions. The p2p gossip for transactions between these layer-2 nodes is logged on HCS and can be verified/audited. +* Trust: End-users can trust this system as long as they can trust a configured number of community consensus nodes is honest. +* Transparency: All consensus node signatures can be verified through the record of the scheduled transactions. The p2p gossip for transactions between these layer-2 nodes is logged on HCS and can be verified/audited. Ethereum tool chain: All existing Ethereum tools should continue to work without any modification, at least in theory. -* State: the state is maintained by the validators and it does not add any tax on Hedera. The state is maintained in the layer-2 smart contracts. Hedera only executes the HAPI transactions (including scheduled transactions), and maintains the accounts and their hbar/token balances. +* State: the state is maintained by the consensus nodes and it does not add any tax on Hedera. The state is maintained in the layer-2 smart contracts. Hedera only executes the HAPI transactions (including scheduled transactions), and maintains the accounts and their hbar/token balances. * Cost: Expected to be significantly cheaper than Ethereum gas costs, but slightly more expensive than native HAPI transactions. Very comparable to the cost of interoperability transactions through decentralized bridges. * Scale: The scale is really dependent on the number of parallel instances of these layer-2 nodes and the number of nodes in each of them. The scale from Hedera mainnet perspective is really the scale of the native cryptotransfer, HCS submit message transactions, and scheduled transactions. * Latency: overall latency will involve sending transactions through HCS, and then submitting the scheduled transaction. Assuming each of these takes around 5-10 seconds, the overall latency is likely to be around 15-25 seconds. * Finality: Transactions notified by mirror node or HCS can be considered to be 100% final. ### Node incentives -To bootstrap, Hedera could incentivize a set of validators. But Hedera does not really define the incentive model for this network. There could be multiple independent instances of these networks and the participants can decide on the incentive models and prices depending on the use cases they serve. The incentive model could be as simple as “everyone who participates gets a share of fees”, which would incentivize smaller networks, or “a selected subset of validators (e.g. determined by a hashing function using the latest consensus timestamp) will get compensated”. In both cases making sure that there is some skin in the game for validators (maybe staked HBAR) would be good to prevent Sybil Attacks. -The validators are known to the smart contract, and the smart contract is coded to distribute the ‘fees’ to the validators equally between the validators who are “active” (defined as those who successfully signed the last m of n transactions). So, if a validator falls off the network, very quickly they will stop receiving payments. The community can write this logic so that this set of ‘active’ validators is deterministically calculated on each validator. +To bootstrap, Hedera could incentivize a set of consensus nodes. But Hedera does not really define the incentive model for this network. There could be multiple independent instances of these networks and the participants can decide on the incentive models and prices depending on the use cases they serve. The incentive model could be as simple as “everyone who participates gets a share of fees”, which would incentivize smaller networks, or “a selected subset of consensus nodes (e.g. determined by a hashing function using the latest consensus timestamp) will get compensated”. In both cases making sure that there is some skin in the game for consensus nodes (maybe staked HBAR) would be good to prevent Sybil Attacks. +The consensus nodes are known to the smart contract, and the smart contract is coded to distribute the ‘fees’ to the consensus nodes equally between the consensus nodes who are “active” (defined as those who successfully signed the last m of n transactions). So, if a consensus node falls off the network, very quickly they will stop receiving payments. The community can write this logic so that this set of ‘active’ consensus nodes is deterministically calculated on each consensus node. ### Deployment and configuration: diff --git a/HIP/hip-13.md b/HIP/hip-13.md index f36ea99cf..5778243f9 100644 --- a/HIP/hip-13.md +++ b/HIP/hip-13.md @@ -14,7 +14,7 @@ updated: 2021-11-30 ## Abstract -The Public Key Infrastructure (PKI) of today is highly centralised with a handful of certificate authorities(CAs) being responsible to validate digital identities(such as domains) by vouching for public keys associated with said identities. This system if highly vulnerable as if any one of the existing list of trusted CAs is compromised so is the entire security of the internet. One solution to this is DNS-based Authentication of Named Entities(DANE) which enables domain owners to store a TSLA record in the Domain Name System(DNS) that defines a contract for how clients can trust a public key is in fact owned by said domain before proceeding to establish a TLS connection. However DANE relies on DNSSEC which relies on a chain of trust akin to that in existing CA PKI as previously mentioned hence is susceptible to similar attacks. +The Public Key Infrastructure (PKI) of today is highly centralised with a handful of certificate authorities(CAs) being responsible to process digital identities(such as domains) by vouching for public keys associated with said identities. This system if highly vulnerable as if any one of the existing list of trusted CAs is compromised so is the entire security of the internet. One solution to this is DNS-based Authentication of Named Entities(DANE) which enables domain owners to store a TSLA record in the Domain Name System(DNS) that defines a contract for how clients can trust a public key is in fact owned by said domain before proceeding to establish a TLS connection. However DANE relies on DNSSEC which relies on a chain of trust akin to that in existing CA PKI as previously mentioned hence is susceptible to similar attacks. By moving DNS (w/ DANE enabled) onto a secure decentralised network such as Hedera security issues resulting from the chain of trust in existing systems are mitigated and if widely adopted would render all existing CAs, DNS stakeholders(ICANN, domain registrars) obsolete. @@ -22,7 +22,7 @@ By moving DNS (w/ DANE enabled) onto a secure decentralised network such as Hede The Hedera Public Ledger is a secure scalable decentralised ledger making it an ideal candidate to supersede existing centralised DNS and PKI systems. Currently the most secure implementations of these systems rely on a chain of trust which is compromised if at least 1-of-m entities in the chain is compromised. The shortcomings inherent to this chain of trust can be mitigated by being replaced with the aBFT consensus of Hedera, hence in order to compromise even a single DNS Resource Record(RR) an attacker must control at least 1/3 of the consensus vote. -Furthermore, the proposed Hedera Name Service(HNS) excels existing systems by enabling the principal owner/s of a domain registered on HNS the ability to update any of their domain's RR at consensus finality speeds(currently <5 seconds), whereas existing infrastructure takes about 1 day for domain propagation. The effective latency would be slightly higher than this as client browsers making for example domain resolution requests would do so to Hedera Mirror Nodes to reduce unnecessary load on MainNet nodes, hence the effective latency would be the MainNet latency offset by the time it takes for any given Mirror Node to reflect the latest consensus round HNS updates. Furthermore, Mirror Nodes(possibly serving as dedicated HNS/DNS resolvers) would respond to requests with a state proof that the client browser would validate either via an HNS browser extension client or the browser's built-in HNS client(assuming browser developers find value in doing so). In addition, any other operations facilitated by HNS such as domain atomic swaps or transfers would also be executed at such speeds, which again is orders of magnitude faster than existing systems that can take up to 7 days to process a domain transfer. +Furthermore, the proposed Hedera Name Service(HNS) excels existing systems by enabling the principal owner/s of a domain registered on HNS the ability to update any of their domain's RR at consensus finality speeds(currently <5 seconds), whereas existing infrastructure takes about 1 day for domain propagation. The effective latency would be slightly higher than this as client browsers making for example domain resolution requests would do so to Hedera Mirror Nodes to reduce unnecessary load on MainNet nodes, hence the effective latency would be the MainNet latency offset by the time it takes for any given Mirror Node to reflect the latest consensus round HNS updates. Furthermore, Mirror Nodes(possibly serving as dedicated HNS/DNS resolvers) would respond to requests with a state proof that the client browser would process either via an HNS browser extension client or the browser's built-in HNS client(assuming browser developers find value in doing so). In addition, any other operations facilitated by HNS such as domain atomic swaps or transfers would also be executed at such speeds, which again is orders of magnitude faster than existing systems that can take up to 7 days to process a domain transfer. ## Rationale diff --git a/HIP/hip-171.md b/HIP/hip-171.md index e85025025..6a3bdc58e 100644 --- a/HIP/hip-171.md +++ b/HIP/hip-171.md @@ -36,7 +36,7 @@ As a developer, I want to know what account sent an HCS message from the message A `payer_account_id` field should be added to the JSON response of `/api/v1/topics/{topicId}/messages`, `/api/v1/topics/{topicId}/messages/{sequenceNumber}`, and `/api/v1/topics/messages/{consensusTimestamp}`. -We already have a `topic_message.payer_account_id` in the table but it is only populated if `chunkInfo` is present in the protobuf. Services validates that if `chunkInfo` is populated that the payer of the transaction must match `chunkInfo.payerAccountId`. So really we can just always populate it with the `transaction.payer_account_id` so it's present for both chunked and non-chunked messages. Then we can return it on the REST API without incurring the cost of a join against the transaction table. This will require a database migration to backfill this data for entries that are null. +We already have a `topic_message.payer_account_id` in the table but it is only populated if `chunkInfo` is present in the protobuf. Services processes that if `chunkInfo` is populated that the payer of the transaction must match `chunkInfo.payerAccountId`. So really we can just always populate it with the `transaction.payer_account_id` so it's present for both chunked and non-chunked messages. Then we can return it on the REST API without incurring the cost of a join against the transaction table. This will require a database migration to backfill this data for entries that are null. So the full topic message REST API response (with consideration for the expanding transactionID object) should become: diff --git a/HIP/hip-173.md b/HIP/hip-173.md index d7421b542..8160bbb7b 100644 --- a/HIP/hip-173.md +++ b/HIP/hip-173.md @@ -34,24 +34,24 @@ exception is to be if the existing schedule has an explicit `payerAccountID` dif ## Motivation -Suppose a validator network is monitoring a stream of events, where each event `e` is uniquely identified +Suppose a consensus node network is monitoring a stream of events, where each event `e` is uniquely identified by a hash `He`, and should trigger the scheduling of a single related transaction `Xe` that needs a majority -of the validators' signatures to execute. +of the consensus nodes' signatures to execute. -Suppose also that the validators all set `memo=He` when trying to schedule transaction `Xe`. Then by the +Suppose also that the consensus nodes all set `memo=He` when trying to schedule transaction `Xe`. Then by the uniqueness of the memos, there is no risk that two identical `ScheduleCreate`s are _actually_ intended for two different events. -Nonetheless, with current network behavior, only the first validator to submit the `ScheduleCreate` for -event `e` will have a "normal" workflow. All the other validators will receive `IDENTICAL_SCHEDULE_ALREADY_CREATED`, +Nonetheless, with current network behavior, only the first consensus node to submit the `ScheduleCreate` for +event `e` will have a "normal" workflow. All the other consensus nodes will receive `IDENTICAL_SCHEDULE_ALREADY_CREATED`, and need to submit a second `ScheduleSign` transaction to attach their signature to the scheduled `Xe` transaction. -This is at best inconvenient, as the network is enforcing protection the validator network simply does not need. +This is at best inconvenient, as the network is enforcing protection the consensus node network simply does not need. ## Rationale Improve the user experience when scheduling transactions on the network, especially in the use case -of a validator network as above. +of a consensus node network as above. ## Specification @@ -88,7 +88,7 @@ keep the same semantics for their `ScheduleCreate` transactions, since the defau ## Security Implications -We do not see any security implications for this change. If a client such as a validator network +We do not see any security implications for this change. If a client such as a consensus node network opts-in to merged scheduling, but cannot ensure duplicate `ScheduleCreate` transactions are always functionally equivalent, it could suffer a correctness failure. But this would be a form of user error, not a problem with the network. diff --git a/HIP/hip-179.md b/HIP/hip-179.md index f31952405..1c00d965d 100644 --- a/HIP/hip-179.md +++ b/HIP/hip-179.md @@ -54,7 +54,7 @@ A websocket based proxy server adhering to CAIP-25 and CAIP-27 JSON-RPC calls will be used to provide signing services. Clients will need to configure and secure access to this websocket service and then use the provided handshake and provider request APIs to sign their transactions. Clients will then either need -to submit the signed transaction or validate the submitted transaction was +to submit the signed transaction or verify the submitted transaction was successfully submitted by the service. ### Signing Proxy Server (CAIP-25 and CAIP-27) @@ -87,7 +87,7 @@ request, `hedera_signTransaction` and `hedera_sendTransaction`. This JSON-RPC method signs a transaction that can be submitted to the network via the existing SDK methods. It is expected there will be some operation on the -other end to validate the signature, possibly including user approval. +other end to process the signature, possibly including user approval. There is one required and one optional parameter: The required parameter is `transaction`, which will be the hex encoded protobuf message that is being @@ -185,7 +185,7 @@ sensible error code and description This JSON-RPC method signs a transaction and then submits it to the hedera network. It is expected there will be some operation on the other end to -validate the signature, possibly including user approval. +process the signature, possibly including user approval. There is one required and one optional parameter: The required parameter is `transaction`, which will be the hex encoded protobuf message that is being diff --git a/HIP/hip-18.md b/HIP/hip-18.md index 7c6baf744..66de034af 100644 --- a/HIP/hip-18.md +++ b/HIP/hip-18.md @@ -563,7 +563,7 @@ new TokenCreateTransaction() In this example, the token created would require 100 tokens with entity ID 0.0.987 to be transferred into the account with entity ID 0.0.123. Account 0.0.123 could obviously be a single individual’s account, or it could be a -multisignature account managed by an HCS based validator network, as we’ve recently seen in Greg Scullard’s NFT auction +multisignature account managed by an HCS based consensus node network, as we’ve recently seen in Greg Scullard’s NFT auction demo ([10](https://www.youtube.com/watch?v=hCPXKR1e7Ro)). This could be expanded to include up to 10 custom fees per token. diff --git a/HIP/hip-206.md b/HIP/hip-206.md index 991927809..3ae717193 100644 --- a/HIP/hip-206.md +++ b/HIP/hip-206.md @@ -149,7 +149,7 @@ Associate and Dissociate are the `associateToken`, `associateTokens`, To support contracts controlling features like minting and burning the defined but up until now unused field `contractID` in the `Key` protobuf message will be utilised. When a token has a contract key as the admin key or one of the admin -keys then that key is considered validated if the `CALLER` of the relevant +keys then that key is considered processed if the `CALLER` of the relevant method is the contract identified in the call. This is the effect of a `CALL` operation in the EVM. diff --git a/HIP/hip-28.md b/HIP/hip-28.md index 36147800e..1ac140944 100644 --- a/HIP/hip-28.md +++ b/HIP/hip-28.md @@ -197,7 +197,7 @@ The basic policy action requirements are: * a policy action must have an input, one or more process steps, and an output. This is just a well-known convention from business process management frameworks. * The input of a policy action must represent a new, proposed state of a policy workflow state object compliant with a policy. * The process steps in a policy action must represent a verification system comprised of the set, or subset, of policy rules and policy data such that an input can be validated to comply with the policy rules and policy data, or not. -* The output of a policy action must represent the validated result of an input into a policy workflow as a correct new policy workflow state. +* The output of a policy action must represent the processed result of an input into a policy workflow as a correct new policy workflow state. Note that a new policy workflow state after a correct policy action execution is defined as diff --git a/HIP/hip-367.md b/HIP/hip-367.md index 1d292ef8d..bd7c1d483 100644 --- a/HIP/hip-367.md +++ b/HIP/hip-367.md @@ -170,7 +170,7 @@ the previous `MerkleTokenRelStatus`. The very last token ID will be the `headTok #### Token Association Token association can occur either explicitly or automatically. In either case, the same algorithm is used, except -that in the case of automatic association we validate that `maxAutomaticAssociations` will not be exceeded by this +that in the case of automatic association we process that `maxAutomaticAssociations` will not be exceeded by this association. Management of `alreadyUsedAutomaticAssociations` remains as it does today and is not altered by this HIP. 1. For each token that is to be associated to the Account, build an `EntityNumPair` from the token ID and account ID @@ -259,7 +259,7 @@ the original balance for treasury on that token is 0. When minting either Fungib Currently, we return `TRANSACTION_REQUIRES_ZERO_TOKEN_BALANCES` when a `cryptoDelete` transaction is submitted on an account with non-zero balances on the tokens [ not `deleted`] that it is associated with. -Checking if the associated token is not `deleted` and then validating the balance on that association gets very costly +Checking if the associated token is not `deleted` and then processing the balance on that association gets very costly when the association limit is removed as we would have to traverse the whole list of associations. Instead, we will include the deleted tokens as well when checking if the account has any non-zero token balances and use the field `numPositiveBalances` to match if all the associations have zero balances so that we can avoid traversing the list of diff --git a/HIP/hip-406.md b/HIP/hip-406.md index 7c049c04a..83e50106c 100644 --- a/HIP/hip-406.md +++ b/HIP/hip-406.md @@ -20,7 +20,7 @@ Hedera is a **Proof of Stake** network. Staking is the process by which a user s ## Motivation -Currently, all nodes are deployed by the governing council, and each node has equal stake. As the network is further decentralized, it becomes important to allow for uneven staking in the networking, and to permit users to choose to which nodes they want to stake their `hbar`. The code for the mainnet nodes needs to be updated to understand and take staking into account when determining consensus, and needs to add support for allowing users to select which node to which they stake (either directly or indirectly). The record files produced by the main nodes need to include staking information and mirror nodes need to take staking information into account when determining a 1/3 *strong minority* for validating record files. The SDKs need to be updated with the API for allowing users to control staking on their accounts. +Currently, all nodes are deployed by the governing council, and each node has equal stake. As the network is further decentralized, it becomes important to allow for uneven staking in the networking, and to permit users to choose to which nodes they want to stake their `hbar`. The code for the mainnet nodes needs to be updated to understand and take staking into account when determining consensus, and needs to add support for allowing users to select which node to which they stake (either directly or indirectly). The record files produced by the main nodes need to include staking information and mirror nodes need to take staking information into account when determining a 1/3 *strong minority* for processing record files. The SDKs need to be updated with the API for allowing users to control staking on their accounts. It is possible for applications to be written and deployed through smart contracts to enable other forms of "staking", completely independent of this HIP. Such contracts can implement novel reward mechanisms like earning NFTs or giving voting rights. This HIP is unrelated to such smart contracts. This HIP discusses only the transactions needed to enable the form of native staking that impacts consensus, ensures security, and enables the possibility in the future of anonymous, permissionless nodes. diff --git a/HIP/hip-410.md b/HIP/hip-410.md index 77bd30536..651e88b42 100644 --- a/HIP/hip-410.md +++ b/HIP/hip-410.md @@ -429,7 +429,7 @@ on HBAR transfers. When the relay and sender accounts are different the following restrictions apply to HBAR transfers. There are three components to consider, first is the total amount of fees Hedera will charge the transaction. The second amount is -the amount of fees the sender has validated to be spent, which is the `gasLimit` +the amount of fees the sender has processed to be spent, which is the `gasLimit` of the transaction multiplied by either the `gasPrice` for Legacy and Type 1 transactions and the `max_fee_per_gas` field for Type 2 transactions. These are the sender authorized fees, and the total transaction amount charged to the @@ -475,7 +475,7 @@ transaction validity check. Each Hedera account will track a new value `ethereumNonce`, defaulting to zero. -When an Ethereum transaction is validated during pre-check the transaction +When an Ethereum transaction is processed during pre-check the transaction will fail if the account's `ethereumNonce` is not equal to the nonce in the Ethereum transaction bytes. @@ -706,7 +706,7 @@ Query Parameters: ### Embedding Ethereum Transaction Directly The signature in the Ethereum transaction is the most critical piece of data, -and must be validated on the exact bytes passed into the signing software. +and must be processed on the exact bytes passed into the signing software. Attempting to re-constitute the signed bytes or “vouch” for a signature (such as custodial bridges) introduce categories of software that diminish the value of a decentralized system. @@ -783,7 +783,7 @@ at [https://github.com/hashgraph/hedera-services/tree/rlp](https://github.com/ha An internal prototype piloted the idea of adding foreign transaction data to all possible transactions, and then populating a normal Hedera transaction with the data from the foreign bytes. Transition logic would need to be updated to either -validate the data matches the foreign bytes or to reject any transaction with +process the data matches the foreign bytes or to reject any transaction with foreign data. This was rejected because it introduced a large amount of data duplication. diff --git a/HIP/hip-534.md b/HIP/hip-534.md new file mode 100644 index 000000000..fddac5936 --- /dev/null +++ b/HIP/hip-534.md @@ -0,0 +1,157 @@ +--- +hip: 534 +title: REGISTRY CONTRACT for naming structure +author: Som Kirann(somkirann@web23.io), Rahul Pandey(rahul@web23.io) +working-group: Som Kirann(somkirann@web23.io), Rahul Pandey(rahul@web23.io), Delfin Iglesia(del@web23.io) +type: Standards Track +category: Application +needs-council-approval: No +status: Stagnant +discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/pull/534 +created: 2022-07-29 +updated: 2024-03-28 +--- + +## Table of Contents + +1. Abstract +2. Motivation +3. Rationale +4. Specification +5. Detailed note on the flow +6. Reference Implementation +7. Rejected Ideas +8. Open Issues +9. References +10. Copyright/license + + +## Abstract + +Fostering overall growth of Hedera, minting of HTLDs (Hedera based -Top-Level-Domains) & SLDs (Second-Level-Domains) within Hedera are open. Any entity, person could mint of the HTLDs & SLDs which could eventually create issues like: +a. Duplication of TLDs; .hbar (for example) by one contract & .hbarby the other contract +b. Duplication of SLDs; for example, minted SLD user.tld by one contract & user.tld by the other contract +c. Inconvenience amongst the community owing to the duplication of names +d. Challenges for the wallets providers to choose one contract over the other + +## Motivation + +To develop a naming standard in registry contracts to prohibit duplicate Hedera specific TLDs and their corresponding Second-Level-Domains, thus allowing multiple parties to mint the routes without worrying of duplicates leading to a healthier ecosystem and new use cases. + +## Rationale + +Taking the motivation, a further step ahead, it is proposed to allow multiple parties who could be resellers, companies to exist within the ecosystem of Hedera and allow community/users to mint/book domains ending in .hbar or any other TLD without the fear of duplication or phishing attempts. +Proposed Hedera centric registry contract that would also be extended to other inter-operable chains in the future would be able to accommodate multiple parties. Same registry contract would contain the real truth of mappings between Account IDs on the Mainnet & the corresponding human readable user-names. For example, john.hbar tied to 0.0.XXXXXXX + +## Specification + +Architecture of the proposed registry contract over Hedera would be, as follows: + +![RegistryContract](https://user-images.githubusercontent.com/97507177/181780608-e6bc217b-ee21-4b6d-a9a4-a28916a5ec87.png) + + +(Image source: https://drive.google.com/file/d/1e3yxtaY8glEiptSXlrNxznxfzTfk1SKr/view) + +## Detailed note on the flow + +**1. What is Registry Contract Suite?**
+Registry Contract Suite is a group of smart Contracts developed over Solidity. These smart contracts are intended to register HTLDs (Hedera Top-Level-Domains) and Second-Level-Domains (SLDs) in a hierarchical manner. SLDs and HTLDs once registered could be queried and looked up to avoid duplication.
+**2. How does Registry Contract Suite Works?**
+Registry Contract Suite is a well structured group of smart contract that maintains an alphabetical hierarchy to register HTLDs and is structured to create and store HTLDs in their respective Alphabetical Registry Component.
+ Once a HTLD is registered by the provider, an entry in respective alphabetical hierarchy smart contract is made. All further domains and subdomains under that hierarchy would be stored in that structure. So that for future, queries for that registered domain names or HTLD/s could be appropriately handled.
+**3. Who are providers and how could someone become a provider of domains/HTLDs?**
+Providers for Registry Contracts are the account addresses of Mainnet of entities who have access to register and update HTLD/s and domains. These providers could do a handful of operations and are provisioned to register a domain/HTLD. All these would be handled by Swirlds Lab or Hbar Foundation.(So that no Provider controls or gate keeps the process)
+To become a provider, entities need to raise a request to the admin of Registry Contracts, who have the privilege to add addresses as providers for the Registry Smart Contract Suite. Initially this would be done through a form accessible via the website of Web23 at web23.io with a goal of moving to a fully decentralized approach.
+**4. Structure of Smart Contracts**
+The structure of smart contracts are as follows: + +a. **AlphaInterface:** This solidity file is an interface and it enables functions and abstract logic for the AToZRegistry Solidity Smart Contract. It enables functionalities such as register HTLD, activate TLD, etc. + +b. **AlphaRegistry:** This solidity file is responsible for doing all the jobs and is exposed for providers. It would internally call different smart contracts from the suite to get the job done. + +c. **UTools:** This smart contract empowers the suite with a handful of utility functions like substring and all. + +d. **AToZRegistry:** This solidity file is responsible for creating an alphabetical order of smart contracts + +e. **Exposed Functionalities and Functions** (may not be in the order) + +i). isTLDAvailable method is used to check whether a particular TLD is available or not.
+**Inputs**:- TLDName
+**Output**:- True or False
+**Scenario** :- This method is an external view function and will return Boolean and is used to Check whether a TLD is available or not
+ +ii). isDomainAvailable method is used to check whether a particular Domain under a TLD is available or not.
+**Inputs**:- DomainName, TLDName
+**Output**:- True or False
+**Scenario** :- This method is an external view function and is used to check whether a particular Domain under a TLD is available or not.
+ +iii). registerTLD method is used to register TLD, only providers who are registered would be able to register a TLD
+**Inputs**:- TldOwnerAddress, TLDName, ChainId, Expiry
+**Output**:- True or False
+**Scenario** :- This method is an external view function and is used to register TLD, only providers who are registered would be able to register a TLD
+ +iv). registerDomain method is used to register domain, only providers who are registered would be able to register a domain
+**Inputs**:- DomainOwnerAdress,TldOwnerAddress,TLDName,DomainName,ChainId,Expiry
+**Output**:- True or False
+**Scenario** :- This method is an external view function and is used to register Domain, only providers who are registered would be able to register a domain
+ +v). activateDomain method is used to activate Domain
+**Inputs**:- DomainName, TLDName
+**Output**:- True or False
+**Scenario** :- This method is an external view function and is used to activate a Domain, only providers who are registered would be able to activate a domain.
+ +vi). deactivateDomain method is used to deactivate a domain
+**Inputs**:- DomainName, TLDName
+**Output**:- True or False
+**Scenario** :- This method is an external view function and is used to deactivate a Domain, only providers who are registered would be able to deactivate a domain.
+ +vii). updateDomainExpiry method is used to update the Domain Expiry
+**Inputs**:- DomainName, TLDName, expiry
+**Output**:- True or False
+**Scenario** :- This method is an external view function and is used to update the Domain Expiry. The expiry should be a greater than the current date.
+ +viii). deactivateTLD method is used to deactivate TLD
+**Inputs**:- TLDName
+**Output**:- True or False
+**Scenario** :- This method is an external view function and is used to deactivate TLD so that no domain under that TLD could be booked.
+ +ix). activateTLD method is used to activate TLD
+**Inputs**:- TLDName
+**Output**:- True or False
+**Scenario** :- This method is an external view function and is used to activate TLD so that domain under that TLD could be booked.
+ +x). updateTLDExpiry method is used to update the TLD Expiry
+**Inputs**:- TLDName,Expiry
+**Output**:- True or False
+**Scenario** :- This method is an external view function and is used to update TLD Expiry
+ +xi). addProvider method is used to add Provider to the Registry, so that they could add TLDs and domains to the Registry.
+**Inputs**:- ProviderWalletAddress
+**Output**:- True or False
+**Scenario** :- This method is an external view function and can be only executed by the administrator/Super Admin of the Smart Contract Suite and is used to add Provider to the Registry , so that they can add TLDs and Domains to the Registry.
+ +xii). getProvider method is used to get Provider by passing their provider ID
+**Inputs**:- ProviderID
+**Output**:- ProviderWalletAddress
+**Scenario** :- Each time a provider is registered , a Provider ID would be allocated by the smart Contract suite and the provider Wallet Address will be mapped/associated with that Provider ID. This method on passing that provider ID, would return the Provider Wallet address of Mainnet.
+ + +## Reference Implementation + +N/A + +## Rejected Ideas + +N/A + +## Open Issues + +N/A + +## References + +N/A + +## Copyright/license + +This document is licensed under the Apache License, Version 2.0 – see, https://www.apache.org/licenses/LICENSE-2.0) diff --git a/HIP/hip-631.md b/HIP/hip-631.md index d1684ae29..af9c6c130 100644 --- a/HIP/hip-631.md +++ b/HIP/hip-631.md @@ -101,7 +101,7 @@ To resolve the issue of account EVM compatibility and identification the proposa To achieve this 1. Hedera accounts can have a list of `evmAddress` values known as “Virtual Address” which govern the address the EVM observes for a given account transaction. -2. The Hedera network will validate ownership by extracting the public key from the signature and comparing the calculated public address to the `evmAddress` passed in on addition of the virtual address and will maintain an `evmAddress` → `accountId` map thereafter. +2. The Hedera network will process ownership by extracting the public key from the signature and comparing the calculated public address to the `evmAddress` passed in on addition of the virtual address and will maintain an `evmAddress` → `accountId` map thereafter. 3. Hedera Accounts can add, disable and remove virtual address entries as desired. Additionally, accounts can update their default virtual address. 4. Each virtual address will have its corresponding nonce tracked and stored in state. 5. The address seen by the EVM per transaction is either the default Hedera address or a verified virtual address specified. diff --git a/HIP/hip-639.md b/HIP/hip-639.md index c850b7e6c..e038c1074 100644 --- a/HIP/hip-639.md +++ b/HIP/hip-639.md @@ -55,7 +55,7 @@ it can avoid the error entirely, and simply use the correct record based on the sync times are sufficiently long that there is no practical reason to ever start a sync from any but the latest snapshot. This means there is no practical benefit to decorating the stream with an errata at some time in the distant past, since no syncing node will ever "be there" to appreciate it. (It is also unclear -how a syncing node would be able to validate signatures on an errata sidecar, since the signatures could +how a syncing node would be able to process signatures on an errata sidecar, since the signatures could come from keys in a future address book that the syncing node knows nothing about.) Therefore we chose not to support errata sidecars. diff --git a/HIP/hip-791.md b/HIP/hip-791.md new file mode 100644 index 000000000..5e70cd28c --- /dev/null +++ b/HIP/hip-791.md @@ -0,0 +1,182 @@ +--- +hip: 791 +title: Hedera Name Protocol +author: Taylor Nielson , Boston McClary +working-group: Brian Coleman +type: Standards Track +category: Application +needs-council-approval: No +status: Stagnant +created: 2023-08-18 +discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/pull/791 +updated: 2023-03-28 +--- + +## Abstract + +This proposal outlines the implementation of the Hedera Name Protocol (HNP), which aims to enhance the Hedera network by introducing a unified and decentralized approach to domain naming, resolution, and governance. The HNP consists of three main components: the HNP Registry, the Resolver, and the Governance/Protocol Management system. + +## Motivation + +Currently, naming services within the Hedera ecosystem operate with isolated registries and resolvers. This approach leads to issues such as duplicate names, vendor lock-in, and centralized control over top-level domains. The HNP aims to address these challenges as well as those listed below by establishing a single source of truth for naming records and introducing a decentralized resolver mechanism with community Governance. +Centralization of the top level domains (TLDs). +- Failed Mints with no refund +- Large quantity of compute executed off chain +- Centralized Wallet Resolver (Owned by a single naming service) +- Insufficient or absent support for delegation and sub-names/sub-domains. +- Overlapping responsibilities: name resolution, registration, and registry information. +- Vendor Lock (Can’t renew names/migrate names from one naming service to another) +- No Community/Stakeholder voting power +- Duplicate NFT’s in the current registry system when purchasing expired names +- No data standards resulting in only partial parity of core functionality between naming services + +## Rationale + +The Hedera Name Protocol (HNP) targets the critical flaws in Hedera's existing centralized and gated domain naming system, particularly the mishandling of expired names and the resulting loss of utility in secondary markets. An alternative of creating a new naming service was considered but dismissed, as it would merely perpetuate centralization. The HNP's innovative design, with a community-driven smart contract infrastructure, directly addresses these challenges, offering a unified, transparent, and decentralized solution. This proposal represents a vital and thoughtful response to existing problems, aligning with Hedera's core principles and reflecting community consensus for a more robust and transparent network. + +## User stories + +N/A + +## Specification + +To address these issues, we propose the Hedera Name Protocol with the following features: + +- A community owned (via governance) smart contract infrastructure to act as a single source of truth for all naming services +- Support for Top Level domain registry, Second Level Domain registry, and Subdomains +- A decentralized governance model executed through smart contracts for community management of the protocol and proper stewardship of the HNP treasury + +### HNP Registry +The HNP Registry will serve as the central repository for all naming records, including top-level domains, second-level domains, and subdomains. The primary objectives of the registry are: + +- Eliminate duplicate names: By maintaining a single global registry, the HNP ensures that naming conflicts are prevented. +- Support multiple naming services: The HNP Registry allows various naming services to access and utilize naming records, promoting competition and user choice. +- Decentralized ownership: The centralized ownership of top-level domains will be replaced with a community-driven governance model. + +### Resolver +The Resolver component of the HNP replaces the existing resolver system. Key features of the HNP Resolver include: + +- Decentralization: The HNP Resolver operates based on a community-led protocol registry, eliminating gatekeeping for second-level domains and subdomains. +- Open access: Any naming service can participate in resolving domain names without requiring approval from a single entity. +- Community-driven gatekeeping: Top-level domain ownership will be managed through a decentralized governance model, ensuring fairness and inclusivity. + +### Governance/Protocol Management +The Governance/Protocol Management aspect of the HNP will be facilitated through a governance token system. Key points regarding this governance system are: + +- Inclusive representation: Governance tokens will be distributed to stakeholders within the community, including wallet providers, naming services, and name purchasers. +- Decision-making authority: Token holders will have the power to propose and vote on protocol features, updates, and treasury allocations. +- Sustainable funding: A controlled minting mechanism will fund the protocol, with the primary goal of supporting maintenance, new feature development, contract, and record rent. + +## Backwards Compatibility + +Backward compatibility in the HNP ensures a seamless transition to the new decentralized framework by referencing the existing registry. This vital feature allows current name providers and users to migrate without disruption or loss, preserving ownership and trust. By honoring existing investments and maintaining continuity, the HNP strikes a powerful balance between innovation and respect for the community's history, setting a precedent for responsible evolution in the Hedera ecosystem. + +## Security Implications + +N/A + +## How to Teach This + +N/A + +## Reference Implementation + +The HNP implementation will involve the following steps: + +1. Smart Contracts: Develop and deploy the necessary smart contracts to enable the HNP Registry, Resolver, and Governance functionalities on the Hedera network. +2. Token Distribution: Distribute governance tokens to eligible community stakeholders, ensuring a fair and inclusive representation. +3. Governance Interface: Create an intuitive interface through which token holders can submit proposals, vote, and manage protocol-related decisions. +4. Migration Plan: Establish a clear migration plan for existing naming services to transition to the HNP, ensuring a smooth transition for users and services. + +### Technical Architecture Reference +https://share.getcloudapp.com/lluXK4ER + +### Technical Interface Reference +#### TLD Factory +createTld - Only by Owner or Governance Protocol - A TLD name (e.g hbar, boo, h) is hashed and sent in as a parameter. If the tld doesn’t exist then a new TLD node is created and a map of the hash => Node Address is added to the factory contract + +getTlds - Public - Returns the hashes of all TLD’s +#### TLD Node +canMint -Internal - Iterates over all SLD Nodes to verify that the name is available + +mintSld- Public - The orchestrator for name minting. It verifies that the name is available for mint, checks that the correct hbar amount (name price/yer * year) is correct, and then executes the mint + +verifiedMintSld - internal - adds the name mapping and ownership to the SLD contract and mints the name NFT to the purchaser + +createSldNode - internal - creates a new SLD node (used when the previous node is full). Adds the address to the list of SLD node addresses and sets the new SLD node address as the current SLD node address. + +getSldNodes - public - returns a list of SLD node addresses + +getSldContract - public - returns the contract address of a specific SLD + +getCurrentSldNode - public - returns the address of the current SLD Node +#### SLD Node +getSldData -public - gets all of the records/mappings/data for an SLD + +addNewSld- owner(of name)- adds a new SLD with the base/initial record values + +updateSld - owner(of name) - add new records/info to a name or updates existing ones +#### Subdomain Factory +createSubdomainNode - internal - creates a new SLD node (used when the previous node is full). Adds the address to the list of SLD node addresses and sets the new SLD node address as the current SLD node address. + +getSubdomainNodes - public - returns a list of SLD node addresses + +getSubdomainContract - public - returns the contract address of a specific SLD + +getCurrentSubdomainContract - public - returns the address of the current Subdomain Node +#### SLD Node +getSubdomainData -public - gets all of the records/mappings/data for an SLD + +addNewSubdomain- owner(of name)/owner of contract (in case it is delegated to another contract) - adds a new SLD with the base/initial record values + +updateSubdomain - owner(of name)/owner of contract (in case it is delegated to another contract) - add new records/info to a name or updates existing ones + +### Technical Explanation of Benefits +The pure smart contract architecture allows for a few upgrades: +- Auto reverts + - Auto refunds upon any failure + - No false payments + - No half mints +- First come First serve + - Due to hederas consensus mechanisms there is guaranteed first minter is the recipient +- No duplicates +- Built in community control/governance + - Values such as cost to mint, whether to add a top level domain, etc can be immediately and programmatically updated upon governance vote and approval +### Technical Overview of Functionality +##### TLD Factory +The TLD Factory is in charge of keeping track of existing TLD’s and minting new ones. Only the owner of the contract (The HNP Council), and an approved governance proposal can create new TLD’s. + +##### TLD Node +The TLD Node is in charge of keeping track of SLD Nodes, the mint price of a domain in USD, what SLD Node is currently writing the new sld’s, verifying that a desired mint sld isn’t already taken, and minting slds. + +##### SLD Node +The SLD Node is in charge of storing minted SLD data + +##### Subdomain Factory +The Subdomain Factory is in charge of keeping track of existing Subdomains that belong to an SLD and minting new ones. Only the owner of the contract, the SLD owner, can mint. + +##### Subdomain Node +The Subdomain Node is in charge of storing Subdomain data + +## Rejected Ideas + +The creation of a new naming service with updated smart contract architecture was considered but rejected in the HNP's development. Though seemingly promising, it was recognized that this approach would merely perpetuate centralization and fail to resolve the existing system's core issues, such as mishandling expired names. The rejection emphasized a commitment to true decentralization and innovation, leading to the HNP's transformative design that aligns with Hedera's principles and addresses the real challenges within the ecosystem. + +## Open Issues + +1. Does HNP create the NFT? Does it create an image overlay? + - Does a subdomain get an NFT? +2. What are the initial criteria for a new TLD? +3. What happens to subdomains when the owning SLD expires or is transferred/sold +4. Can people mint directly from the protocol? + - If so, what is the purpose of a naming service? +5. Who will be on the foundational council to own governance starting out? + + +## References + +A collections of URLs used as references through the HIP. + +## Copyright/license + +This document is licensed under the Apache License, Version 2.0 -- see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0) diff --git a/HIP/hip-796.md b/HIP/hip-796.md index 3e317ac23..3af66e24e 100644 --- a/HIP/hip-796.md +++ b/HIP/hip-796.md @@ -566,7 +566,7 @@ message TokenUnlockTransactionBody { ### CryptoTransfer Handling Changes -When validating a crypto transfer, the consensus node will validate that the sum of all transfers balances to zero. It is not legal to debit one account by 10 hbars and fail to credit another account by the same amount. Likewise, it is not legal to remove an NFT from one account without also adding it to another, or debit some fungible tokens from one account and fail to credit another. +When processing a crypto transfer, the consensus node will process that the sum of all transfers balances to zero. It is not legal to debit one account by 10 hbars and fail to credit another account by the same amount. Likewise, it is not legal to remove an NFT from one account without also adding it to another, or debit some fungible tokens from one account and fail to credit another. However, since all partitions of the same `token-definition` are fungible, we need to alter the rule for checking that all transfers balance to zero. When signed by the appropriate `partition-move-key`, the balance check will verify that the sum of all `token-definition` transfers will balance to zero. diff --git a/HIP/hip-830.md b/HIP/hip-830.md index 4ea03d48f..86ea9518b 100644 --- a/HIP/hip-830.md +++ b/HIP/hip-830.md @@ -19,7 +19,7 @@ This HIP proposes several changes to the event serialization format. 1. Add the `birthRound` to the metadata of new events. The `birthRound` value is 1 + the latest round to have come to consensus at the time the event was created. This value is used to determine if the event is ancient or not. - It is also used to look up the correct consensus roster for validating the event's signature. + It is also used to look up the correct consensus roster for processing the event's signature. 2. Represent references to parent events as `EventDescriptors`. EventDescriptors combine the existing data about each parent and the birthRound into a single data structure: EventDescriptor(hash, creator, generation, birthRound). 3. Allow for multiple other parents. @@ -31,7 +31,7 @@ This HIP proposes several changes to the event serialization format. The `birthRound` of an event is 1+ the latest round to have come to consensus at the time the event was created. The `birthRound` is used to determine if an event is ancient or not and to look up the correct roster for -validating the event's signature. +processing the event's signature. ### EventDescriptors as Parent Event References diff --git a/HIP/hip-867.md b/HIP/hip-867.md index 4ef363454..6403622f2 100644 --- a/HIP/hip-867.md +++ b/HIP/hip-867.md @@ -79,7 +79,7 @@ automatically be part of the Besu EVM Library implementation. It is expected the gas cost of the precompile will fall in line with compute usage during the execution. Performance tests will need to be executed to -validate that heavy use of the precompile matches this expectation. +process that heavy use of the precompile matches this expectation. ## How to Teach This diff --git a/about-hips.html b/about-hips.html index a0bed7293..e44d86a1f 100644 --- a/about-hips.html +++ b/about-hips.html @@ -70,7 +70,7 @@

HIP Types

  • Application: Application standards may be used to standardize software in the Hedera ecosystem that aren't mirror or consensus nodes. This includes application network software, external contract - validators, multi-sig oracles, persistence mechanisms, enterprise software plugins, etc. An example of + consensus nodes, multi-sig oracles, persistence mechanisms, enterprise software plugins, etc. An example of an Application standard would be the Stablecoin Contract and Non-fungible Token Contract written in Java as a layer-2 solution using the Hedera Consensus service to maintain trust.