diff --git a/README.md b/README.md index 74d1433a5..b90395ad5 100644 --- a/README.md +++ b/README.md @@ -4,66 +4,93 @@ [![](https://img.shields.io/badge/view-published-blue)](https://hips.hedera.com) ## Submit a HIP - 1. Fork this repository -2. Fill out this template: [hip template](hip-0000-template.md) -3. Create a pull request against hashgraph/hedera-improvement-proposal main - -But what category do I make my HIP? See [hip-1 HIP types](HIP/hip-1.md#hip-types) - -See [hip-1](HIP/hip-1.md) for details on the HIP process or watch [this video](https://www.youtube.com/watch?v=Gbk8EbtibA0) +1. Fill out this template: [hip template](hip-0000-template.md) + 1. If the proposal contains exceptionally large specification text, + particularly API changes or source code, place those changes + in `assets` and link them as described in the template document. +1. Create a pull request against hashgraph/hedera-improvement-proposal main +
+
But what category do I make my HIP?
+
See hip-1 HIP types.
+
+ +See [hip-1](HIP/hip-1.md) for details on the HIP process or watch +[this video](https://www.youtube.com/watch?v=Gbk8EbtibA0) ## What is a HIP? - -HIP stands for "Hedera Improvement Proposal". These improvement proposals can range from core protocol changes, to the applications, frameworks, and protocols built on top of the Hedera public network and used by the community. The HIP author is responsible for building consensus within the community and documenting dissenting opinions, as well as tracking their HIP through the process outlined below. +HIP stands for "Hedera Improvement Proposal". These improvement proposals can +range from core protocol changes, to the applications, frameworks, and protocols +built on top of the Hedera public network and used by the community. The HIP +author is responsible for building consensus within the community and +documenting dissenting opinions, as well as tracking their HIP through +the process outlined below. You can see the list of all HIPs on [the official HIPs site](https://hips.hedera.com). ## What is Hedera Hashgraph? - -[Hedera Hashgraph](https://hedera.com) is the only public network built on top of [Dr. Leemon Baird](http://www.leemon.com/)’s [Hashgraph consensus algorithm](http://www.leemon.com/papers/2016b.pdf). Hedera goes beyond blockchain to provide the fast, fair, and secure environment needed to enable enterprise adoption of distributed ledger technologies. You can learn more about Hedera by [reading the Hedera whitepaper](https://hedera.com/whitepaper), and for a more detailed understanding of the Hashgraph Consensus Algorithm you can check out the [hashgraph algorithm whitepaper](http://www.leemon.com/papers/2016b.pdf). +[Hedera Hashgraph](https://hedera.com) is the only public network built on top +of [Dr. Leemon Baird](http://www.leemon.com/)’s +[Hashgraph consensus algorithm](http://www.leemon.com/papers/2016b.pdf). +Hedera goes beyond blockchain to provide the fast, fair, and secure environment +needed to enable enterprise adoption of distributed ledger technologies. You +can learn more about Hedera by +[reading the Hedera whitepaper](https://hedera.com/whitepaper), and for a more +detailed understanding of the Hashgraph Consensus Algorithm you can check out +the [hashgraph algorithm whitepaper](http://www.leemon.com/papers/2016b.pdf). ## Purpose - -The goal of HIPs is to have a place to propose new features, to collect community thoughts and input on a particular issue, and further to document all these subject matters in one place. It’s a great way to document these discussions and proposals [here on GitHub](https://github.com/hashgraph/hedera-improvement-proposal), because any [revisions made on these text files will be recorded](https://github.com/hashgraph/hedera-improvement-proposal/commits/master). +The goal of HIPs is to have a place to propose new features, to collect +community thoughts and input on a particular issue, and further to document +all these subject matters in one place. It’s a great way to document these +discussions and proposals +[here on GitHub](https://github.com/hashgraph/hedera-improvement-proposal), +because any +[revisions made on these text files will be recorded](https://github.com/hashgraph/hedera-improvement-proposal/commits/master). ## Qualifications - -Each HIP should only be one single key proposal and/or idea. The idea should be focused and only issue to one subject matter to be successful. A HIP must meet certain minimum criteria: it must be clear and have a complete description of the proposed enhancement, the enhancement must represent a net improvement, the proposed implementation, if applicable, must be solid and must not complicate the protocol unduly. +Each HIP should only be one single key proposal and/or idea. The idea should be +focused and only issue to one subject matter to be successful. A HIP must meet +certain minimum criteria: it must be clear and have a complete description of +the proposed enhancement, the enhancement must represent a net improvement, +the proposed implementation, if applicable, must be solid and must not +complicate the protocol unduly. ## Before Submitting - -1. Evaluate your idea: consider why you’d like to request changes or improvements, and how it benefits the Hedera Hashgraph community. - -2. Thoroughly look through those proposals already submitted to ensure there are no duplicates. - -3. Ask the Hedera Hashgraph community first if your idea is original, or has already been through the HIP process. - -4. Reevaluate your proposal to ensure sure the idea is applicable to the entire community and not just to one particular author, application, project, or protocol. +1. Evaluate your idea: consider why you’d like to request changes or + improvements, and how it benefits the Hedera Hashgraph community. +1. Thoroughly look through those proposals already submitted to ensure there + are no duplicates. +1. Ask the Hedera Hashgraph community first if your idea is original, or has + already been through the HIP process. +1. Reevaluate your proposal to ensure sure the idea is applicable + to the entire community and not just to one particular author, application, + project, or protocol. ## Local Jekyll Site - Pre-requisites: - - `ruby`: `2.7.8p225` - `gem`: `3.4.10` - `bundler`: `1.17.3` - You can run a local version of the HIPs dashboard site: - ```shell bundle install bundle exec jekyll serve --livereload ``` - The site will be available on `http://localhost:4000`. You can read more about Jekyll on its official [website](https://jekyllrb.com/) ##### Note - -An excellent place to discuss your proposal and get feedback is in the [issues section of this repository](https://github.com/hashgraph/hip/issues), or on [Hedera's Discord Server](https://hedera.com/discord); there you can start formalizing the language around your HIP and ensuring it has broad community support. +An excellent place to discuss your proposal and get feedback is in the +[issues section of this repository](https://github.com/hashgraph/hip/issues), +or on [Hedera's Discord Server](https://hedera.com/discord); there you can +start formalizing the language around your HIP and ensuring it has broad +community support. ## Disclaimer(s): - -These proposals and discussions have no effect regarding private (permissioned) implementations of the Hashgraph consensus algorithm; additionally, this repository and it’s contents are run by the Hedera Hashgraph community, which means they do not necessarily reflect the views and opinions of Hedera Hashgraph LLC. +These proposals and discussions have no effect regarding private (permissioned) +implementations of the Hashgraph consensus algorithm; additionally, this +repository and it’s contents are run by the Hedera Hashgraph community, which +means they do not necessarily reflect the views and opinions of +Hedera Hashgraph LLC. diff --git a/assets/hip-0000-template/sample.proto b/assets/hip-0000-template/sample.proto new file mode 100644 index 000000000..c302dcdf1 --- /dev/null +++ b/assets/hip-0000-template/sample.proto @@ -0,0 +1,117 @@ +/** + * # Token Airdrop + * Messages used to implement a transaction to "airdrop" tokens.
+ * An "airdrop" is a distribution of tokens from a funding account + * to one or more recipient accounts, ideally with no action required + * by the recipient account(s). + * + * ### Keywords + * The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + * "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + * document are to be interpreted as described in + * [RFC2119](https://www.ietf.org/rfc/rfc2119) and clarified in + * [RFC8174](https://www.ietf.org/rfc/rfc8174). + */ +syntax = "proto3"; + +package proto; + +/* + * Copyright (C) 2024 Hedera Hashgraph, LLC + * + * Licensed under the Apache License, Version 2.0 (the "License"); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +option java_package = "com.hederahashgraph.api.proto.java"; +// <<>> This comment is special code for setting PBJ Compiler java package +option java_multiple_files = true; + +import "basic_types.proto"; + +/** + * Airdrop one or more tokens to one or more accounts. + * + * ### Effects + * This distributes tokens from the balance of one or more sending account(s) + * to the balance of one or more recipient accounts. Accounts MAY receive the + * tokens in one of four ways. + * + * - An account already associated to the token to be distributed SHALL + * receive the airdropped tokens immediately to the recipient account + * balance.
+ * The fee for this transfer SHALL include the transfer, the airdrop fee, + * and any custom fees. + * - An account with available automatic association slots SHALL be + * automatically associated to the token, and SHALL immediately receive + * the airdropped tokens to the recipient account balance.
+ * The fee for this transfer SHALL include the transfer, the association, + * the cost to renew that association once, the airdrop fee, and + * any custom fees. + * - An account with "receiver signature required" set SHALL have a + * "Pending Airdrop" created and must claim that airdrop with a + * `claimAirdrop` transaction.
+ * The fee for this transfer SHALL include the transfer, the association, + * the cost to renew that association once, the airdrop fee, and + * any custom fees.
+ * If the pending airdrop is not claimed immediately, the `sender` SHALL + * pay the cost to renew the token association, and the cost to maintain + * the pending airdrop, until the pending airdrop is claimed or cancelled. + * - An account with no available automatic association slots SHALL have a + * "Pending Airdrop" created and must claim that airdrop with a + * `claimAirdrop` transaction.
+ * The fee for this transfer SHALL include the transfer, the association, + * the cost to renew that association once, the airdrop fee, and any custom + * fees.
+ * If the pending airdrop is not claimed immediately, the `sender` SHALL + * pay the cost to renew the token association, and the cost to maintain + * the pending airdrop, until the pending airdrop is claimed or cancelled. + * + * If an airdrop would create a pending airdrop for a fungible/common token, + * and a pending airdrop for the same sender, receiver, and token already + * exists, the existing pending airdrop SHALL be updated to add the new + * amount to the existing airdrop, rather than creating + * a new pending airdrop.
+ * Any airdrop that completes immediately SHALL be irreversible. Any airdrop + * that results in a "Pending Airdrop" MAY be canceled via a `cancelAirdrop` + * transaction.
+ * All transfer fees (including custom fees and royalties), as well as the + * rent cost for the first auto-renewal period for any automatic-association + * slot occupied by the airdropped tokens, SHALL be charged to the account + * paying for this transaction.
+ * + * ### Block Stream Effects + * - Each successful transfer SHALL be recorded in `token_transfer_list` + * for the transaction record. + * - Each successful transfer that consumes an automatic association slot + * SHALL populate the `automatic_association` field for the record. + * - Each pending transfer _created_ SHALL be added to the + * `pending_airdrops` field for the record. + * - Each pending transfer _updated_ SHALL be added to the + * `pending_airdrops` field for the record. + */ +message TokenAirdropTransactionBody { + /** + * A list of token transfers representing one or more airdrops. + *

+ * The sender for each transfer MUST have sufficient balance to complete + * the transfers.
+ * All token transfers MUST successfully transfer tokens or create a + * pending airdrop for this transaction to succeed.
+ * This list MUST contain between 1 and 10 transfers, inclusive. + *

+ * Note that each transfer of fungible/common tokens requires both a debit + * and a credit, so each _fungible_ token transfer MUST have _balanced_ + * entries in the TokenTransferList for that transfer. + */ + repeated TokenTransferList token_transfers = 1; +} diff --git a/hip-0000-template.md b/hip-0000-template.md index 98dedeef0..dd5713ba4 100644 --- a/hip-0000-template.md +++ b/hip-0000-template.md @@ -9,7 +9,7 @@ category: <"Core" | "Service" | "Mirror" | "Application"> needs-council-approval: <"Yes" | "No"> status: <"Draft" | "Review" | "Last Call" | "Active" | "Inactive" | "Deferred" | "Rejected" | "Withdrawn" | "Accepted" | "Final" | "Replaced"> created: -discussions-to: +discussions-to: updated: requires: replaces: @@ -17,57 +17,108 @@ superseded-by: --- ## Abstract - Please provide a short (~200 word) description of the issue being addressed. -## Motivation +This abstract should be copied to the description for your pull request. -The motivation is critical for HIPs that want to change the Hedera codebase or ecosystem. It should clearly explain why the existing specification is inadequate to address the problem that the HIP solves. HIP submissions without sufficient motivation may be rejected outright. +## Motivation +The motivation is critical for HIPs that want to change the Hedera codebase or +ecosystem. It should clearly explain why the existing specification is +inadequate to address the problem that the HIP solves. HIP submissions without +sufficient motivation may be rejected outright. ## Rationale +The rationale fleshes out the specification by describing why particular design +decisions were made. It should describe alternate designs that were considered +and related work, e.g. how the feature is supported in other languages. -The rationale fleshes out the specification by describing why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. - -The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during the discussion. +The rationale should provide evidence of consensus within the community and +discuss important objections or concerns raised during the discussion. ## User stories +Provide a list of "user stories" to express how this feature, functionality, +improvement, or tool will be used by the end user. Template for user story: +“As (user persona), I want (to perform this action) so that (I can accomplish +this goal).” -Provide a list of "user stories" to express how this feature, functionality, improvement, or tool will be used by the end user. Template for user story: “As (user persona), I want (to perform this action) so that (I can accomplish this goal).” - ## Specification - -The technical specification should describe the syntax and semantics of any new features. The specification should be detailed enough to allow competing, interoperable implementations for at least the current Hedera ecosystem. +The technical specification should describe the syntax and semantics of any new +features. The specification should be detailed enough to allow competing, +interoperable implementations for at least the current Hedera ecosystem. + +Some specifications are of exceptional (thousands of lines) size. If your HIP +requires detail of this level, add the large segments of specification as +files of appropriate type (e.g. Solidity code, Protocol Buffer definition, +Java code, etc...) in the `assets` folder, and add descriptive links +to each such file here. +### Example Specification +

+ +Add a new `TokenAirdrop` transaction to `HederaFunctionality`. +```protobuf +enum HederaFunctionality { +// ... + /** + * Airdrops one or more tokens to one or more accounts. + */ + TokenAirdrop = 94; +} +``` + +Define a new `TokenAirdrop` transaction body. This transaction distributes +tokens from the balance of one or more sending account(s) to the balance of +one or more recipient accounts. Accounts MAY receive the tokens in one of +four ways. The full definition, for clarity, is detailed +in [an attached file](assets/hip-0000-template/sample.proto). + +
+ +Some HIP specifications are not well served by this mechanism. In these cases +the HIP MAY initially specify a public github commit or PR, and the HIP +administrator may work with the authors to define an alternative method to +include an appropriate snapshot of the specification content on +a case-by-case basis. ## Backwards Compatibility - -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. +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. ## Security Implications - -If there are security concerns in relation to the HIP, those concerns should be explicitly addressed to make sure reviewers of the HIP are aware of them. +If there are security concerns in relation to the HIP, those concerns should be +explicitly addressed to make sure reviewers of the HIP are aware of them. ## How to Teach This - -For a HIP that adds new functionality or changes interface behaviors, it is helpful to include a section on how to teach users, new and experienced, how to apply the HIP to their work. +For a HIP that adds new functionality or changes interface behaviors, it is +helpful to include a section on how to teach users, new and experienced, how to +apply the HIP to their work. ## Reference Implementation - -The reference implementation must be complete before any HIP is given the status of “Final”. The final implementation must include test code and documentation. +The reference implementation must be complete before any HIP is given the status +of “Final”. The final implementation must include test code and documentation. ## Rejected Ideas +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 both helps record the thought process behind the +final version of the HIP as well as preventing people from bringing up the same +rejected idea again in subsequent discussions. -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 both helps record the thought process behind the final version of the HIP as well as preventing people from bringing up the same rejected idea again in subsequent discussions. - -In a way, this section can be thought of as a breakout section of the Rationale section that focuses specifically on why certain ideas were not ultimately pursued. +In a way, this section can be thought of as a breakout section of the Rationale +section that focuses specifically on why certain ideas were not ultimately +pursued. ## Open Issues - -While a HIP is in draft, ideas can come up which warrant further discussion. Those ideas should be recorded so people know that they are being thought about but do not have a concrete resolution. This helps make sure all issues required for the HIP to be ready for consideration are complete and reduces people duplicating prior discussions. +While a HIP is in draft, ideas can come up which warrant further discussion. +Those ideas should be recorded so people know that they are being thought about +but do not have a concrete resolution. This helps make sure all issues required +for the HIP to be ready for consideration are complete and reduces people +duplicating prior discussions. ## 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) +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-534.md b/hip-534.md deleted file mode 100644 index fddac5936..000000000 --- a/hip-534.md +++ /dev/null @@ -1,157 +0,0 @@ ---- -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-791.md b/hip-791.md deleted file mode 100644 index 5e70cd28c..000000000 --- a/hip-791.md +++ /dev/null @@ -1,182 +0,0 @@ ---- -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)