37 | * This value SHALL be the result of a corresponding
38 | * `UtilService` `prng` transaction.
39 | */
40 | bytes prng_bytes = 1;
41 |
42 | /**
43 | * A deterministic pseudo-random number generated within a
44 | * specified range.
45 | *
46 | * This value SHALL be the result of a corresponding `UtilService`
47 | * `prng` transaction.
48 | * Note that the transaction only permits a non-negative range, the
49 | * output SHALL always be a whole number.
50 | */
51 | uint32 prng_number = 2;
52 | }
53 | }
54 |
--------------------------------------------------------------------------------
/MAINTAINERS.md:
--------------------------------------------------------------------------------
1 | # Maintainers
2 |
3 | The general handling of Maintainer rights and all groups in this GitHub org is done in the https://github.com/hiero-ledger/governance repository.
4 |
5 | ## Maintainer Scopes, GitHub Roles and GitHub Teams
6 |
7 | Maintainers are assigned the following scopes in this repository:
8 |
9 | | Scope | Definition | GitHub Role | GitHub Team |
10 | |---------------------|-----------------------------------|-------------|--------------------------------------------|
11 | | project-maintainers | The Maintainers of the project | Maintain | `hiero-improvement-proposals-maintainers` |
12 | | tsc | The Hiero TSC | Maintain | `tsc` |
13 | | github-maintainers | The Maintainers of the github org | Maintain | `github-maintainers` |
14 |
15 | ## Active Maintainers
16 |
17 |
18 |
19 | | Name | GitHub ID | Scope | LFID | Discord ID | Email | Company Affiliation |
20 | |---------------- | -------------- | ---------- | ---- | ----------------- | ----- | ------------------- |
21 | | Serg Metelin | sergmetelin | Maintainer | | | | Hashgraph |
22 | | Michael Garber | mgarbs | Maintainer | | michael_garber_87 | | Hashgraph |
23 | | Raphael Messian | RaphaelMessian | Maintainer | | | | Hashgraph |
24 |
25 |
26 | ## Emeritus Maintainers
27 |
28 | | Name | GitHub ID | Scope | LFID | Discord ID | Email | Company Affiliation |
29 | |----- | --------- | ----- | ---- | ---------- | ----- | ------------------- |
30 | | | | | | | | |
31 |
32 | ## The Duties of a Maintainer
33 |
34 | Maintainers are expected to perform duties in alignment with **[Hiero-Ledger's defined maintainer guidelines](https://github.com/hiero-ledger/governance/blob/main/roles-and-groups.md#maintainers).**
35 |
--------------------------------------------------------------------------------
/HIP/hip-372.md:
--------------------------------------------------------------------------------
1 | ---
2 | hip: 372
3 | title: Entity Auto-Renewals and Expiry Window
4 | author: Leemon Baird (@lbaird), Nosh Mody (@noshmody), Quan Nguyen (@qnswirlds)
5 | type: Standards Track
6 | category: Service
7 | needs-council-approval: Yes
8 | status: Final
9 | last-call-date-time: 2022-03-21T07:00:00Z
10 | created: 2022-03-01
11 | discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/discussions/382
12 | replaces: 16
13 | updated: 2023-01-20
14 | ---
15 |
16 | ## Abstract
17 |
18 | Slight modifications of the auto-renewal duration window compared to the original HIP-16.
19 |
20 | ## Motivation
21 |
22 | The original HIP-16 mentions the auto renewal duration between ~81 days and ~92 days. The rationale was to provide a wider window for the auto-renew duration periodfor better flexibility.
23 |
24 | ## Rationale
25 |
26 | Refer to HIP-16.
27 |
28 | ## User stories
29 |
30 | Refer to HIP-16.
31 |
32 | ## Specification
33 |
34 | The minimum auto-renew period will be equal to ~30 days (2,592,000 seconds), and the max auto-renew durtaion will remain equal to ~92 days (8,000,001 seconds).
35 |
36 | ## Backwards Compatibility
37 |
38 | This feature is not enabled on the Mainnet and should therefore be backwards compatible.
39 |
40 | ## Security Implications
41 |
42 | N/A
43 |
44 | ## How to Teach This
45 |
46 | Implementation of this feature will be referenced in release notes, supported by SDKs, as well as supported at docs.hedera.com.
47 |
48 |
49 | ## Reference Implementation
50 |
51 | The reference implementation change from the original HIP-16 is modifying `ledger.autoRenewPeriod.minDuration` from ~81 days to 30 days.
52 |
53 | ```
54 | ledger.autoRenewPeriod.maxDuration=8000001 seconds // ~92 days
55 | ledger.autoRenewPeriod.minDuration=2592000 seconds // ~30 days
56 | ```
57 |
58 |
59 | ## Rejected Ideas
60 |
61 | N/A
62 |
63 | ## Open Issues
64 |
65 | N/A
66 |
67 | ## References
68 |
69 | HIP-16: https://hips.hedera.com/hip/hip-16
70 |
71 | ## Copyright/license
72 |
73 | This document is licensed under the Apache License, Version 2.0 -- see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0)
74 |
--------------------------------------------------------------------------------
/assets/hip-15/HIP-15-mathematica.nb.txt:
--------------------------------------------------------------------------------
1 | (* (c) 2020-2021 Hedera Hashgraph,released under Apache 2.0 license.*)
2 |
3 | (* find the HIP-15 checksum for a given Hedera address and ledger ID *)
4 |
5 | checksum[ledgerId_, address_] :=
6 | Module[{h, d, p3, p5, s0, s1, s, sh, c, cp},
7 | h = Join[ledgerId, {0, 0, 0, 0, 0, 0}];
8 | d = (ToCharacterCode[address] //. {46 -> 10 + 48}) - 48; (* "." is 46, "0" is 48 *)
9 | p3 = 26^3;
10 | p5 = 26^5;
11 | sd0 = Mod[Total[d[[1 ;; Length[d] ;; 2]]], 11];
12 | sd1 = Mod[Total[d[[2 ;; Length[d] ;; 2]]], 11];
13 | sd = Fold[Mod[#1*31 + #2, p3] &, d];
14 | sh = Fold[Mod[#1*31 + #2, p5] &, h];
15 | c = Mod[((Mod[Length[d], 5]*11 + sd0)*11 + sd1)*p3 + sd + sh, p5];
16 | cp = Mod[c*1000003, p5];
17 | StringJoin @@
18 | FromCharacterCode[(IntegerDigits[cp, 26, 5] +
19 | ToCharacterCode["a"][[1]])]];
20 |
21 | (* Output the given ledger ID and address along with the calculated \
22 | checksum *)
23 |
24 | output[ledgerId_, address_] :=
25 | Print["ledger: ", ledgerId, " address: ", address, "-",
26 | checksum[ledgerId, address]];
27 |
28 | (* Output checksums for all the examples given in HIP-15 *)
29 |
30 | addresses = {"0.0.1", "0.0.4", "0.0.5", "0.0.6", "0.0.12", "0.0.123",
31 | "0.0.1234567890", "12.345.6789", "1.23.456"};
32 | output[{0}, #] & /@ addresses;
33 | output[{161, 255, 1}, #] & /@ addresses;
34 |
35 | (*
36 | OUTPUT:
37 | ledger:{0} address:0.0.1-dfkxr
38 | ledger:{0} address:0.0.4-cjcuq
39 | ledger:{0} address:0.0.5-ktach
40 | ledger:{0} address:0.0.6-tcxjy
41 | ledger:{0} address:0.0.12-uuuup
42 | ledger:{0} address:0.0.123-vfmkw
43 | ledger:{0} address:0.0.1234567890-zbhlt
44 | ledger:{0} address:12.345.6789-aoyyt
45 | ledger:{0} address:1.23.456-adpbr
46 | ledger:{161,255,1} address:0.0.1-xzlgq
47 | ledger:{161,255,1} address:0.0.4-xdddp
48 | ledger:{161,255,1} address:0.0.5-fnalg
49 | ledger:{161,255,1} address:0.0.6-nwxsx
50 | ledger:{161,255,1} address:0.0.12-povdo
51 | ledger:{161,255,1} address:0.0.123-pzmtv
52 | ledger:{161,255,1} address:0.0.1234567890-tvhus
53 | ledger:{161,255,1} address:12.345.6789-vizhs
54 | ledger:{161,255,1} address:1.23.456-uxpkq
55 | *)
56 |
--------------------------------------------------------------------------------
/_config.yml:
--------------------------------------------------------------------------------
1 | # Welcome to Jekyll!
2 | #
3 | # This config file is meant for settings that affect your whole blog, values
4 | # which you are expected to set up once and rarely edit after that. If you find
5 | # yourself editing this file very often, consider using Jekyll's data files
6 | # feature for the data you need to update frequently.
7 | #
8 | # For technical reasons, this file is *NOT* reloaded automatically when you use
9 | # 'bundle exec jekyll serve'. If you change this file, please restart the server process.
10 |
11 | # Site settings
12 | # These are used to personalize your new site. If you look in the HTML files,
13 | # you will see them accessed via {{ site.title }}, {{ site.email }}, and so on.
14 | # You can create any custom variable you would like, and they will be accessible
15 | # in the templates via {{ site.myvariable }}.
16 | title: Hiero Improvement Proposals
17 | description: >- # this means to ignore newlines until "baseurl:"
18 | HIP stands for Hiero Improvement Proposal”. These improvement proposals can range from core protocol changes, to the applications, frameworks, and protocols built on top of the Hiero public network and used by the community.
19 | baseurl: "" # the subpath of your site, e.g. /blog
20 | url: "" # the base hostname & protocol for your site, e.g. http://example.com
21 | twitter_username: hedera
22 | github_username: hiero-ledger
23 |
24 | # Order for displaying HIP statuses
25 | hip_status_order:
26 | - Last Call
27 | - Draft
28 | - Approved
29 | - Accepted
30 | - Final
31 | - Active
32 | - Review
33 | - Stagnant
34 | - Deferred
35 | - Withdrawn
36 | - Rejected
37 | - Replaced
38 |
39 | # Build settings
40 | markdown: kramdown
41 | theme: minima
42 |
43 | defaults:
44 | -
45 | scope:
46 | path: "HIP"
47 | values:
48 | layout: "hip"
49 |
50 | include:
51 | - _data
52 |
53 | # Exclude from processing.
54 | # The following items will not be processed, by default. Create a custom list
55 | # to override the default setting.
56 | exclude:
57 | - Gemfile
58 | - Gemfile.lock
59 | - node_modules
60 | - vendor/bundle/
61 | - vendor/cache/
62 | - vendor/gems/
63 | - vendor/ruby/
64 | - hip-0000-template.md
65 | - .gitignore
66 | - CODE_OF_CONDUCT.md
67 | - LICENSE
68 | - README.md
69 |
--------------------------------------------------------------------------------
/assets/hip-1056/protobuf/stream/block.proto:
--------------------------------------------------------------------------------
1 | /**
2 | * # Block Stream
3 | * The base element of the block stream _at rest_.
4 | * A `Block` contains a record of all transactions, results, and outputs for
5 | * a block in the chain. Each `Block` also contains a state proof for
6 | * validation and a header with version and algorithm information.
7 | *
8 | * Block entries are not designed for streaming, but for storing blocks in
9 | * persistent storage, verifying block stream data, and as query responses
10 | * when a block is requested from a block node.
11 | *
12 | * ### Keywords
13 | * The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
14 | * "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
15 | * document are to be interpreted as described in
16 | * [RFC2119](https://www.ietf.org/rfc/rfc2119) and clarified in
17 | * [RFC8174](https://www.ietf.org/rfc/rfc8174).
18 | */
19 | syntax = "proto3";
20 |
21 | package com.hedera.hapi.block.stream;
22 |
23 | // SPDX-License-Identifier: Apache-2.0
24 |
25 | option java_package = "com.hedera.hapi.block.stream.protoc";
26 | // <<>> This comment is special code for setting PBJ Compiler java package
27 | option java_multiple_files = true;
28 |
29 | import "stream/block_item.proto";
30 |
31 | /**
32 | * A single complete Hedera block chain block.
33 | *
34 | * This is a single block structure and SHALL NOT represent the primary
35 | * mechanism to transmit a block stream.
36 | * The primary mechanism for transmitting block stream data SHALL be to
37 | * stream individual block items to the block node(s).
38 | * The only delimiter between blocks when streamed SHALL be the `BlockHeader`
39 | * item and `BlockProof` item.
40 | *
41 | * This block SHALL be verifiable as correct using only data in the block,
42 | * including the `BlockProof`, and public keys for the consensus nodes.
43 | */
44 | message Block {
45 | /**
46 | * A list of items that, together, make up this block.
47 | *
48 | * This list SHALL begin with a `BlockHeader`.
49 | * This list SHALL end with a `BlockProof`.
50 | * Items in this list SHALL be in exactly the same order produced by
51 | * consensus.
52 | * Items in this list MAY be filtered, if so requested.
53 | * If this list is filtered, removed items SHALL be replaced with
54 | * `FilteredBlockItem` entries.
55 | */
56 | repeated BlockItem items = 1;
57 | }
58 |
--------------------------------------------------------------------------------
/assets/hip-1056/protobuf/services/contract_types.proto:
--------------------------------------------------------------------------------
1 | /**
2 | * # Contract Message Types
3 | * Message types used in contract transactions.
4 | *
5 | * ### Keywords
6 | * The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
7 | * "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
8 | * document are to be interpreted as described in
9 | * [RFC2119](https://www.ietf.org/rfc/rfc2119) and clarified in
10 | * [RFC8174](https://www.ietf.org/rfc/rfc8174).
11 | */
12 | syntax = "proto3";
13 |
14 | package proto;
15 |
16 | // SPDX-License-Identifier: Apache-2.0
17 | option java_package = "com.hederahashgraph.api.proto.java";
18 | // <<>> This comment is special code for setting PBJ Compiler java package
19 | option java_multiple_files = true;
20 |
21 | import "services/basic_types.proto";
22 | import "google/protobuf/wrappers.proto";
23 |
24 | /**
25 | * Context of an internal call in an EVM transaction that is not otherwise externalized.
26 | * This message does not say anything about whether an EVM transaction is itself a logical
27 | * transaction in a Hiero transactional unit. It simply provides context on an internal
28 | * message call within an EVM transaction.
29 | */
30 | message InternalCallContext {
31 | /**
32 | * The gas available for the call.
33 | */
34 | uint64 gas = 1;
35 |
36 | /**
37 | * The value sent with the call.
38 | */
39 | uint64 value = 2;
40 |
41 | /**
42 | * The call data for the call.
43 | */
44 | bytes call_data = 3;
45 | }
46 |
47 | /**
48 | * Results of executing a EVM transaction.
49 | */
50 | message EvmTransactionResult {
51 | /**
52 | * The Hedera id of the caller.
53 | */
54 | AccountID sender_id = 1;
55 |
56 | /**
57 | * The Hedera id of the contract receiving the call.
58 | */
59 | ContractID contract_id = 2;
60 |
61 | /**
62 | * Result data from the function call.
63 | */
64 | bytes result_data = 3;
65 |
66 | /**
67 | * Any error message produced by the contract call. Max size of 100 bytes.
68 | *
69 | * This SHALL be unset if the contract call succeeded.
70 | */
71 | string error_message = 4;
72 |
73 | /**
74 | * EVM gas used.
75 | */
76 | uint64 gas_used = 5;
77 |
78 | /**
79 | * If not already externalized in a transaction body, the context of the
80 | * internal call producing this result.
81 | */
82 | InternalCallContext internal_call_context = 6;
83 | }
84 |
--------------------------------------------------------------------------------
/Gemfile.lock:
--------------------------------------------------------------------------------
1 | GEM
2 | remote: https://rubygems.org/
3 | specs:
4 | addressable (2.8.0)
5 | public_suffix (>= 2.0.2, < 5.0)
6 | colorator (1.1.0)
7 | concurrent-ruby (1.2.0)
8 | em-websocket (0.5.2)
9 | eventmachine (>= 0.12.9)
10 | http_parser.rb (~> 0.6.0)
11 | eventmachine (1.2.7)
12 | ffi (1.15.4)
13 | forwardable-extended (2.6.0)
14 | http_parser.rb (0.6.0)
15 | i18n (0.9.5)
16 | concurrent-ruby (~> 1.0)
17 | jekyll (3.9.0)
18 | addressable (~> 2.4)
19 | colorator (~> 1.0)
20 | em-websocket (~> 0.5)
21 | i18n (~> 0.7)
22 | jekyll-sass-converter (~> 1.0)
23 | jekyll-watch (~> 2.0)
24 | kramdown (>= 1.17, < 3)
25 | liquid (~> 4.0)
26 | mercenary (~> 0.3.3)
27 | pathutil (~> 0.9)
28 | rouge (>= 1.7, < 4)
29 | safe_yaml (~> 1.0)
30 | jekyll-feed (0.15.1)
31 | jekyll (>= 3.7, < 5.0)
32 | jekyll-sass-converter (1.5.2)
33 | sass (~> 3.4)
34 | jekyll-seo-tag (2.7.1)
35 | jekyll (>= 3.8, < 5.0)
36 | jekyll-watch (2.2.1)
37 | listen (~> 3.0)
38 | kramdown (2.3.1)
39 | rexml
40 | kramdown-parser-gfm (1.1.0)
41 | kramdown (~> 2.0)
42 | liquid (4.0.3)
43 | listen (3.7.0)
44 | rb-fsevent (~> 0.10, >= 0.10.3)
45 | rb-inotify (~> 0.9, >= 0.9.10)
46 | mercenary (0.3.6)
47 | minima (2.5.1)
48 | jekyll (>= 3.5, < 5.0)
49 | jekyll-feed (~> 0.9)
50 | jekyll-seo-tag (~> 2.1)
51 | pathutil (0.16.2)
52 | forwardable-extended (~> 2.6)
53 | public_suffix (4.0.6)
54 | rb-fsevent (0.11.0)
55 | rb-inotify (0.10.1)
56 | ffi (~> 1.0)
57 | rexml (3.2.8)
58 | strscan (>= 3.0.9)
59 | rouge (3.26.0)
60 | safe_yaml (1.0.5)
61 | sass (3.7.4)
62 | sass-listen (~> 4.0.0)
63 | sass-listen (4.0.0)
64 | rb-fsevent (~> 0.9, >= 0.9.4)
65 | rb-inotify (~> 0.9, >= 0.9.7)
66 | sawyer (0.8.2)
67 | addressable (>= 2.3.5)
68 | faraday (> 0.8, < 2.0)
69 | simpleidn (0.2.1)
70 | unf (~> 0.1.4)
71 | strscan (3.1.0)
72 | terminal-table (1.8.0)
73 | unicode-display_width (~> 1.1, >= 1.1.1)
74 | thread_safe (0.3.6)
75 | tzinfo (1.2.10)
76 | thread_safe (~> 0.1)
77 | tzinfo-data (1.2021.4)
78 | tzinfo (>= 1.0.0)
79 | wdm (0.1.1)
80 | webrick (1.7.0)
81 |
82 | PLATFORMS
83 | ruby
84 |
85 | DEPENDENCIES
86 | jekyll (~> 3.9.0)
87 | jekyll-feed (~> 0.6)
88 | kramdown-parser-gfm
89 | minima (~> 2.0)
90 | tzinfo (~> 1.2)
91 | tzinfo-data
92 | wdm (~> 0.1.0)
93 | webrick (~> 1.7)
94 |
95 | BUNDLED WITH
96 | 1.17.3
97 |
--------------------------------------------------------------------------------
/HIP/hip-1126.md:
--------------------------------------------------------------------------------
1 | ---
2 | hip: 1126
3 | title: Delete Allowance without Token Association
4 | author: Michael Heinrichs <@netopyr>
5 | requested-by: GitHub issue https://github.com/hiero-ledger/hiero-consensus-node/issues/17441
6 | type: Standards Track
7 | category: Service
8 | needs-hedera-review: Yes
9 | needs-hiero-approval: Yes
10 | status: Accepted
11 | last-call-date-time: 2025-03-17T07:00:00Z
12 | created: 2025-02-17
13 | discussions-to: https://github.com/hiero-ledger/hiero-consensus-node/issues/17441
14 | updated: 2025-03-03
15 | ---
16 |
17 | ## Abstract
18 | To remove an allowance for a token, the token must be associated with the account.
19 | This is an unnecessary burden with no advantages.
20 | This HIP proposes to allow the removal of allowances without requiring the token to be associated.
21 |
22 | ## Motivation
23 | If a user wants to remove an allowance for a token without an association, one has to associate the token, remove the allowance, and dissociate the token again.
24 | This is a cumbersome and expensive process with no benefits.
25 | A user may decide to keep the allowances instead, which wastes resources and risks hitting the limit of allowed allowances.
26 |
27 | While it makes sense to associate the token before giving a non-zero allowance, it does not make sense that the token must be associated in order for the allowance to be removed.
28 |
29 | ## Rationale
30 | `CryptoDeleteAllowance` is used to delete allowances on NFTs. Once this HIP is implemented, it does not require the owner to have an association with the token.
31 |
32 | To delete the allowance of a fungible token, a user has to send a `CryptoApproveAllowance` with an amount of `0`. After this HIP is implemented, the owner does not require an association with the fungible token to execute this transaction.
33 |
34 | ## User stories
35 | 1. As a user, I want to remove an allowance without having to associate the token with my account first.
36 |
37 | ## Specification
38 | This change requires no changes to the HAPI or the record stream/block stream.
39 |
40 | ## Backwards Compatibility
41 | This HIP is fully backward compatible. It does not change the behavior of any existing functionality except for allowing the deletion of allowances in previously forbidden cases.
42 |
43 | ## Security Implications
44 | There are no security implications. Removing an allowance imposes no security risk.
45 |
46 | ## How to Teach This
47 | The `CryptoDeleteAllowance` and `CryptoApproveAllowance` documentation should be updated to reflect the new behavior.
48 |
49 | ## Copyright/license
50 | This document is licensed under the Apache License, Version 2.0 --
51 | see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0)
52 |
--------------------------------------------------------------------------------
/HIP/hip-1049.md:
--------------------------------------------------------------------------------
1 | ---
2 | hip: 1049
3 | title: Deleted flag in ConsensusGetTopic
4 | author: Michael Heinrichs
5 | requested-by: Hashgraph
6 | type: Standards Track
7 | category: Service
8 | needs-council-approval: Yes
9 | status: Accepted
10 | last-call-date-time: 2024-11-05T07:00:00Z
11 | created: 2024-09-19
12 | discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/pull/1049
13 | updated: 2024-11-06
14 | ---
15 |
16 | ## Abstract
17 |
18 | This HIP proposes to add a `deleted` flag to the response of a `ConsensusGetTopicInfo`-query.
19 |
20 | ## Motivation
21 |
22 | Knowing if a topic has been deleted is essential for many use cases. Query results for all other entity types contain this information but are missing for topics.
23 |
24 | ## Rationale
25 |
26 | Deleted entities are not immediately removed but marked as being deleted. Queries return these entities. The response for other entity types (e.g., `Account`, `Token`) contains a `deleted` flag that is `true` if the entity has been removed.
27 |
28 | The results of `ConsensusGetTopicInfo`-queries do not contain such a flag. This information is crucial for many use cases. For instance, a deleted topic should not be used anymore.
29 |
30 | ## User stories
31 |
32 | As a user, I want to know if a `Topic` has been deleted.
33 |
34 | ## Specification
35 |
36 | The message `ConsensusTopicInfo` is returned as a response to a `ConsensusGetTopicInfo`-query. It contains a deleted flag, which is true if the entity has been removed and false otherwise.
37 |
38 | ```protobuf
39 | message ConsensusTopicInfo {
40 |
41 | [...]
42 |
43 | /**
44 | * Specifies whether the topic was deleted or not
45 | */
46 | bool deleted = 10;
47 | }
48 | ```
49 |
50 | ## Backwards Compatibility
51 |
52 | The attribute is additional and can safely be ignored by existing code.
53 |
54 | ## Security Implications
55 |
56 | The new flag imposes no new security risk.
57 |
58 | ## How to Teach This
59 |
60 | Documentation for the `ConsensusGetTopicInfo`-query has to be updated.
61 |
62 | ## Reference Implementation
63 |
64 | _The reference implementation must be complete before any HIP is given the status of “Final”. The final implementation must include test code and documentation._
65 |
66 | ## Rejected Ideas
67 |
68 | An enum `state` with the states `ACTIVE` and `DELETED` would have been extensible. However, we use a `deleted` flag already in similar situations and decided to be consistent.
69 |
70 | ## Open Issues
71 |
72 | None.
73 |
74 | ## References
75 |
76 | N/A
77 |
78 | ## Copyright/license
79 |
80 | This document is licensed under the Apache License, Version 2.0 -- see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0)
81 |
--------------------------------------------------------------------------------
/HIP/hip-394.md:
--------------------------------------------------------------------------------
1 | ---
2 | hip: 394
3 | title: Add Expected Decimal Information to TokenMint, TokenBurn, and TokenWipeAccount
4 | author: Ryan Leckey
5 | type: Standards Track
6 | category: Service
7 | needs-council-approval: Yes
8 | status: Accepted
9 | last-call-date-time: 2022-04-05T07:00:00Z
10 | created: 2022-03-08
11 | discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/discussions/393
12 | updated: 2023-01-20
13 | ---
14 |
15 | ## Abstract
16 |
17 | This specification proposes a way to add expected decimal information for tokens to
18 | the `TokenMint`, `TokenBurn`, and `TokenWipeAccount` transaction.
19 |
20 | ## Motivation
21 |
22 | The motivation for this HIP is identical to the motivation for [HIP-31](./hip-31.md).
23 | These additional transactions also need the decimal information for use in a hardware wallet.
24 |
25 | ## Rationale
26 |
27 | The below change to token transfer protobuf messages is formulated to incur a minimal operational cost to the network while providing enough information to address hardware wallet security concerns.
28 |
29 | ## Specification
30 |
31 | ```java
32 | message TokenMintTransactionBody {
33 | // [...]
34 |
35 | /**
36 | * If present, the number of decimals this fungible token type is expected to have. The transfer
37 | * will fail with UNEXPECTED_TOKEN_DECIMALS if the actual decimals differ.
38 | */
39 | UInt32Value expected_decimals = 4;
40 | }
41 |
42 | message TokenBurnTransactionBody {
43 | // [...]
44 |
45 | /**
46 | * If present, the number of decimals this fungible token type is expected to have. The transfer
47 | * will fail with UNEXPECTED_TOKEN_DECIMALS if the actual decimals differ.
48 | */
49 | UInt32Value expected_decimals = 4;
50 | }
51 |
52 | message TokenWipeAccountTransactionBody {
53 | // [...]
54 |
55 | /**
56 | * If present, the number of decimals this fungible token type is expected to have. The transfer
57 | * will fail with UNEXPECTED_TOKEN_DECIMALS if the actual decimals differ.
58 | */
59 | UInt32Value expected_decimals = 5;
60 | }
61 |
62 | ```
63 |
64 | ## Backwards Compatibility
65 |
66 | It shouldn't break existing messages, and will provide needed information for some applications going forward.
67 |
68 | ## Security Implications
69 |
70 | A Ledger hardware wallet user would be able to trust that the fractional display of a token transfer is coming from an on wire message that they are signing with their private key.
71 |
72 | ## References
73 |
74 | HIP-31: https://hips.hedera.com/hip/hip-31
75 |
76 | ## Copyright/license
77 |
78 | This document is licensed under the Apache License, Version 2.0 -- see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0)
79 |
--------------------------------------------------------------------------------
/assets/hip-1056/protobuf/stream/output/file_service.proto:
--------------------------------------------------------------------------------
1 | /**
2 | * # File Service
3 | * Block stream messages that report the results of transactions handled
4 | * by the `File` service.
5 | *
6 | * A `file` in Hedera is an arbitrary sequence of bytes and may be up to
7 | * `1048576` total bytes. Files are used anywhere a transaction requires a
8 | * large amount of data (anything that would not fit within the
9 | * transaction size limit).
10 | *
11 | * Examples
12 | * - smart contract bytecode
13 | * - network configuration updates
14 | * - network fee schedules
15 | * - image files for NFTs
16 | * - property title documents
17 | * There are many other uses; these examples are illustrative.
18 | *
19 | * ### Keywords
20 | * The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
21 | * "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
22 | * document are to be interpreted as described in
23 | * [RFC2119](https://www.ietf.org/rfc/rfc2119) and clarified in
24 | * [RFC8174](https://www.ietf.org/rfc/rfc8174).
25 | */
26 | syntax = "proto3";
27 |
28 | package com.hedera.hapi.block.stream.output;
29 |
30 | // SPDX-License-Identifier: Apache-2.0
31 |
32 | option java_package = "com.hedera.hapi.block.stream.output.protoc";
33 | // <<>> This comment is special code for setting PBJ Compiler java package
34 | option java_multiple_files = true;
35 |
36 | /**
37 | * Block Stream data for a `fileAppend` transaction.
38 | *
39 | * This message SHALL NOT duplicate information already contained
40 | * in the original transaction.
41 | */
42 | message AppendFileOutput {}
43 |
44 | /**
45 | * Block Stream data for a `fileCreate` transaction.
46 | *
47 | * This message SHALL NOT duplicate information already contained in
48 | * the original transaction.
49 | */
50 | message CreateFileOutput {}
51 |
52 | /**
53 | * Block Stream data for a `fileDelete` transaction.
54 | *
55 | * This message SHALL NOT duplicate information already contained in
56 | * the original transaction.
57 | */
58 | message DeleteFileOutput {}
59 |
60 | /**
61 | * Block Stream data for a `fileUpdate` transaction.
62 | *
63 | * This message SHALL NOT duplicate information already contained in
64 | * the original transaction.
65 | */
66 | message UpdateFileOutput {}
67 |
68 | /**
69 | * Block Stream data for a `systemDelete` transaction.
70 | *
71 | * This message SHALL NOT duplicate information already contained in
72 | * the original transaction.
73 | */
74 | message SystemDeleteOutput {}
75 |
76 | /**
77 | * Block Stream data for a `systemUndelete` transaction.
78 | *
79 | * This message SHALL NOT duplicate information already contained in
80 | * the original transaction.
81 | */
82 | message SystemUndeleteOutput {}
83 |
--------------------------------------------------------------------------------
/assets/js/tooltip.js:
--------------------------------------------------------------------------------
1 | document.addEventListener("DOMContentLoaded", function () {
2 | const statusTooltipElements = document.querySelectorAll(".status-tooltip");
3 | statusTooltipElements.forEach(tooltip => {
4 | tooltip.addEventListener("mouseover", () => {
5 | const tooltipText = tooltip.getAttribute("data-tooltip");
6 | const tooltipBox = document.createElement("div");
7 | tooltipBox.classList.add("status-tooltip-box");
8 | tooltipBox.innerText = getTooltipContent(tooltipText);
9 | tooltip.appendChild(tooltipBox);
10 | });
11 |
12 | tooltip.addEventListener("mouseout", () => {
13 | const tooltipBox = tooltip.querySelector(".status-tooltip-box");
14 | if (tooltipBox) tooltip.removeChild(tooltipBox);
15 | });
16 |
17 | tooltip.addEventListener("mousemove", (event) => {
18 | const tooltipBox = tooltip.querySelector(".status-tooltip-box");
19 | if (tooltipBox) {
20 | const boxRect = tooltipBox.getBoundingClientRect();
21 | const contentLength = tooltipBox.innerText.length;
22 | const offset = contentLength < 125 ? 100 : 200;
23 | const tooltipLeft = Math.max(0, event.clientX + offset);
24 | tooltipBox.style.left = tooltipLeft + "px";
25 | tooltipBox.style.maxWidth = (window.innerWidth - event.clientX) * 2 + "px";
26 | }
27 | });
28 |
29 | });
30 | });
31 |
32 | function getTooltipContent(status) {
33 | const statusMeanings = {
34 | Draft: "✏️ The formal starting point of a HIP. Currently being drafted and not yet ready for review.",
35 | Review: "📖 Ready for review by the community and HIP editors. Subject to changes; feedback appreciated.",
36 | "Last Call": "📢 Final review window (typically 14 days) before moving to Hiero TSC approval or Approved status.",
37 | Approved: "✅ Standards Track HIP approved by Hiero TSC, or Application HIP approved by community. Awaits Hedera review if needed.",
38 | Final: "🎯 Standards Track HIP with reference implementation merged and code released.",
39 | Active: "🌟 Process or Informational HIP that is currently in effect. Can be Withdrawn or Replaced.",
40 | Deferred: "⏸️ Not currently being pursued but may be revisited in the future.",
41 | Withdrawn: "🛑 Withdrawn by the Author(s). Can be resurrected as a new proposal.",
42 | Stagnant: "🚧 No activity for 6+ months. Can return to Draft by Authors or Editors.",
43 | Rejected: "❌ Rejected by HIP editors, community, or Hiero TSC vote. Ideas recorded with reasoning.",
44 | Replaced: "🔄 Overwritten by a newer standard or implementation."
45 | };
46 | return statusMeanings[status] || "No information available for this status.";
47 | }
--------------------------------------------------------------------------------
/HIP/hip-31.md:
--------------------------------------------------------------------------------
1 | ---
2 | hip: 31
3 | title: Add Token Transfer Decimal Information
4 | author: Chris Campbell
5 | type: Standards Track
6 | category: Service
7 | needs-council-approval: Yes
8 | status: Final
9 | last-call-date-time: 2021-12-21T07:00:00Z
10 | release: v0.22.0
11 | created: 2021-10-14
12 | discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/issues/165
13 | updated: 2022-04-26
14 | ---
15 |
16 | ## Abstract
17 |
18 | This specification proposes a way to provide on wire token decimal information, by splitting the amount field in token transfers into a whole and fractional part.
19 |
20 | ## Motivation
21 |
22 | As of drafting this HIP, [Ledger](https://www.ledger.com/) is the only hardware wallet to support Hedera Hashgraph. In a recent review of the Ledger [BOLOS application for Hedera](https://github.com/LedgerHQ/app-hedera), the Ledger development team flagged the current scheme for providing decimal information for display of token transfers on device as posing a security risk. The current version of the Ledger BOLOS app provides decimals as a parameter passed separately from the transaction body that will be signed. This can potentially lead to manipulation of display of the token transfer amount to shift the decimal place for an attacker's benefit (i.e by tricking a user into signing a transaction that is off by orders of magnitude). The app currently works this way because the protobuf messages for token transfers do not include decimal information, and client wallets must therefore look up this information using a query (at cost) or a mirror node, and then pass this information to the device using a general parameter.
23 |
24 | The motivation for the proposed change is to solve this problem. Token transfers can be modified to provide enough information in their transaction bodies that applications parsing on wire token transfer messages can correctly and verifiably display the transfer information.
25 |
26 | ## Rationale
27 |
28 | The below change to token transfer protobuf messages is formulated to incur a minimal operational cost to the network while providing enough information to address hardware wallet security concerns.
29 |
30 | ## Specification
31 |
32 | ```
33 | message TokenTransferList {
34 | // [...]
35 |
36 | /**
37 | * If present, the number of decimals this fungible token type is expected to have. The transfer
38 | * will fail with UNEXPECTED_TOKEN_DECIMALS if the actual decimals differ.
39 | */
40 | UInt32Value expected_decimals = 4;
41 | }
42 | ```
43 |
44 | ## Backwards Compatibility
45 |
46 | It shouldn't break existing token transfer messages, and will provide needed information for some applications going forward.
47 |
48 | ## Security Implications
49 |
50 | A Ledger hardware wallet user would be able to trust that the fractional display of a token transfer is coming from an on wire message that they are signing with their private key.
51 |
--------------------------------------------------------------------------------
/.github/workflows/send-discord-message.yml:
--------------------------------------------------------------------------------
1 | name: Send discord notification
2 | on:
3 | workflow_dispatch:
4 | inputs:
5 | filename:
6 | description: "Filename"
7 | type: string
8 | required: true
9 | status:
10 | description: "Status"
11 | type: string
12 | required: true
13 |
14 | permissions:
15 | contents: read
16 | actions: write
17 |
18 | defaults:
19 | run:
20 | shell: bash
21 |
22 | jobs:
23 | StatusChangeNotifications:
24 | runs-on: hiero-improvement-proposals-linux-medium
25 | steps:
26 | - name: Harden Runner
27 | uses: step-security/harden-runner@95d9a5deda9de15063e7595e9719c11c38c90ae2 # v2.13.2
28 | with:
29 | egress-policy: audit
30 |
31 | - name: Checkout repository
32 | uses: actions/checkout@1af3b93b6815bc44a9784bd300feb67ff0d1eeb3 # v6.0.0
33 |
34 | - name: Extract HIP abstract
35 | id: extract_abstract
36 | env:
37 | FILENAME: ${{ github.event.inputs.filename }}
38 | run: |
39 | # Add .md extension if not present
40 | if [[ "$FILENAME" == *.md ]]; then
41 | HIP_FILE="HIP/${FILENAME}"
42 | else
43 | HIP_FILE="HIP/${FILENAME}.md"
44 | fi
45 |
46 | # Verify file exists
47 | if [ ! -f "$HIP_FILE" ]; then
48 | echo "Error: File $HIP_FILE does not exist"
49 | echo "abstract=File not found: $HIP_FILE" >> "$GITHUB_OUTPUT"
50 | exit 0
51 | fi
52 |
53 | # Extract the abstract section (text between "## Abstract" and the next "##" heading)
54 | ABSTRACT=$(sed -n '/^## Abstract$/,/^## /p' "$HIP_FILE" | sed '$d' | tail -n +2 | sed '/^$/d')
55 |
56 | # If abstract is empty, use a default message
57 | if [ -z "$ABSTRACT" ]; then
58 | ABSTRACT="No abstract available for this HIP."
59 | fi
60 |
61 | # Save the abstract to output (escape for GitHub Actions)
62 | {
63 | echo "abstract<> "$GITHUB_OUTPUT"
67 |
68 | # Save the filename without extension for URL
69 | FILENAME_NO_EXT="${FILENAME%.md}"
70 | echo "filename_no_ext=$FILENAME_NO_EXT" >> "$GITHUB_OUTPUT"
71 |
72 | - name: Discord notification
73 | env:
74 | DISCORD_WEBHOOK: ${{ secrets.DISCORD }}
75 | uses: step-security/action-discord@12bdaf0579698ae72d3caf0cc14578ced05f9bed # v0.1.4
76 | with:
77 | args: |
78 | # ${{ steps.extract_abstract.outputs.filename_no_ext }} moved into ${{ github.event.inputs.status }} status
79 |
80 | ## About this HIP
81 | ${{ steps.extract_abstract.outputs.abstract }}
82 |
83 | Read the full HIP here:
84 | https://hips.hedera.com/hip/${{ steps.extract_abstract.outputs.filename_no_ext }}
85 |
--------------------------------------------------------------------------------
/HIP/hip-213.md:
--------------------------------------------------------------------------------
1 | ---
2 | hip: 213
3 | title: Application Signs for End User
4 | author: Justin Atwell , Greg Scullard
5 | type: Informational
6 | needs-council-approval: No
7 | status: Active
8 | discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/discussions/304
9 | last-call-date-time: 2021-12-21T07:00:00Z
10 | created: 2021-11-13
11 | updated: 2021-12-07
12 | ---
13 |
14 | ## Abstract
15 |
16 | Describes the concept of how transactions can be issued by one account, but paid for by another account.
17 |
18 | ## Motivation
19 |
20 | Oftentimes it is appropriate for the application to pay fees associated with a transation rather than the end user.
21 |
22 | ## Rationale
23 |
24 | N/A
25 |
26 | ## User stories
27 |
28 | As an end user that does not want to incur transaction fees on the network, I still want the ability to hold tokens on the Hedera network
29 |
30 | ## Specification
31 |
32 | ```
33 | //Java
34 |
35 | private AccountId getAccountId() throws TimeoutException, PrecheckStatusException, ReceiptStatusException {
36 | // Retrieve the Operator Id
37 | AccountId OPERATOR_ID = AccountId.fromString(Objects.requireNonNull(Dotenv.load().get("OPERATOR_ID")));
38 |
39 | // need a placeholder key to satisfy the client.setOperator;
40 | PrivateKey dummyKey = PrivateKey.generate();
41 |
42 | //Create a testnet Client
43 | Client client = Client.forTestnet();
44 |
45 | // Set the operator (and default signer) to the new private key
46 | client.setOperator(OPERATOR_ID, dummyKey);
47 |
48 | // We need the public key of the operator id for the signWith operation below
49 | PublicKey OPERATOR_PUBLIC_KEY = PrivateKey.fromString(Dotenv.load().get("OPERATOR_KEY")).getPublicKey();
50 |
51 | // Creates a function that is invoked during the signWith method
52 | Function transactionSigner = generateSignatureFunction();
53 |
54 | // Create a TransferTransaction that transfers 1 tinyBar from the operator to account 0.0.3
55 | TransactionResponse response = new TransferTransaction()
56 | .addHbarTransfer(OPERATOR_ID, Hbar.fromTinybars(1).negated())
57 | .addHbarTransfer(AccountId.fromString("0.0.3"), Hbar.fromTinybars(1))
58 | .freezeWith(client)
59 | .signWith(OPERATOR_PUBLIC_KEY, transactionSigner)
60 | .execute(client);
61 | TransactionReceipt receipt = response.getReceipt(client);
62 |
63 | return receipt.accountId;
64 | }
65 |
66 | private Function generateSignatureFunction() {
67 | // Retrieve the Private Key from the .env file
68 | PrivateKey OPERATOR_KEY = PrivateKey.fromString(Objects.requireNonNull(Dotenv.load().get("OPERATOR_KEY")));
69 |
70 | // return a function that will sign the byte array transaction during the signWith method
71 | return (
72 | t -> OPERATOR_KEY.sign(t)
73 | );
74 | }
75 | ```
76 |
77 | ## Copyright/license
78 |
79 | This document is licensed under the Apache License, Version 2.0 -- see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0)
80 |
--------------------------------------------------------------------------------
/HIP/hip-564.md:
--------------------------------------------------------------------------------
1 | ---
2 | hip: 564
3 | title: Zero unit token operations in smart contracts
4 | author: Matthew DeLorenzo , Vae Vecturne
5 | type: Standards Track
6 | category: Service
7 | needs-council-approval: Yes
8 | status: Final
9 | last-call-date-time: 2022-09-21T07:00:00Z
10 | release: v0.31.0
11 | created: 2022-09-01
12 | discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/discussions/563
13 | updated: 2023-02-01
14 | ---
15 |
16 | ## Abstract
17 |
18 | Integer rounding will naturally lead to DeFi contracts sometimes minting or transferring 0 units of a token. But the network rejects 0 units in these operations, forcing contract developers to include special cases that would not be necessary on most networks.
19 |
20 | ## Motivation
21 |
22 | Currently, whenever a zero value parameter passes through a mint, burn or transfer transaction, the network rejects it immediately. Frequently this happens with integer rounding calculations in smart contracts. To get around it, contract developers must check for a non-zero value to submit mint, burn or transfer transactions, which is inconsistent with most other networks. This hip will eliminate `if` statements checking for zero before mint, burn or transfer transactions in smart contracts making them easier to use and be in alignment with most other networks.
23 |
24 | ## Rationale
25 |
26 | DeFi contracts using ERC20 standard may mint, burn, and transfer zero tokens.
27 |
28 | When we deprecate farms in our farm contracts by giving them a weighting of 0, the network rejects 0 units in these operations, forcing contract developers to include special cases that would not be necessary on most networks. Currently, all 'SafeHederaTokenService' calls (meaning they require HederaResponseCode.SUCCESS) must be qualified with a statement `if(amount > 0)`, as a 0 amount would result in HederaResponseCode.INVALID_TOKEN_MINT_AMOUNT or similar.
29 |
30 | Importantly, ERC20 token standard allows for 0 amount mint, burn, transfer, etc.
31 |
32 | ## User stories
33 |
34 | As a solidity developer, I would like to send 0 tokens in my smart contracts.
35 |
36 | ## Specification
37 |
38 | The response code for token mint, burn, and transfer returns SUCCESS = 22
39 |
40 | ## Backwards Compatibility
41 |
42 | This would be backward compatible.
43 |
44 | ## Security Implications
45 |
46 | N/A
47 |
48 | ## How to Teach This
49 |
50 | N/A
51 |
52 | ## Reference Implementation
53 | #### Example :
54 | Example of a mint transaction that should be allowed if a 0 amount is passed.
55 |
56 | ```js
57 | function mint(uint amount) external {
58 | balanceOf[msg.sender] += amount;
59 | totalSupply += amount;
60 | emit Transfer(address(0), msg.sender, amount);
61 | }
62 | ```
63 |
64 | ## Rejected Ideas
65 |
66 |
67 |
68 | ## Open Issues
69 |
70 |
71 |
72 | ## References
73 |
74 |
75 |
76 | ## Copyright/license
77 |
78 | This document is licensed under the Apache License, Version 2.0 -- see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0)
79 |
--------------------------------------------------------------------------------
/assets/hip-1056/protobuf/stream/output/crypto_service.proto:
--------------------------------------------------------------------------------
1 | /**
2 | * # Crypto Service
3 | * Block stream messages that report the results of transactions handled by
4 | * the `Crypto` service. This service primarily handles account management
5 | * and HBAR transfers.
6 | *
7 | * > Note
8 | * >> Tokens other than HBAR, including all NFTs, are managed by the `Token` Service.
9 | *
10 | * ### Keywords
11 | * The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
12 | * "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
13 | * document are to be interpreted as described in
14 | * [RFC2119](https://www.ietf.org/rfc/rfc2119) and clarified in
15 | * [RFC8174](https://www.ietf.org/rfc/rfc8174).
16 | */
17 | syntax = "proto3";
18 |
19 | package com.hedera.hapi.block.stream.output;
20 |
21 | // SPDX-License-Identifier: Apache-2.0
22 |
23 | option java_package = "com.hedera.hapi.block.stream.output.protoc";
24 | // <<>> This comment is special code for setting PBJ Compiler java package
25 | option java_multiple_files = true;
26 |
27 | import "custom_fees.proto";
28 |
29 | /**
30 | * Block Stream data for a `approveAllowances` transaction.
31 | *
32 | * This message SHALL NOT duplicate information already contained in
33 | * the original transaction.
34 | */
35 | message ApproveAllowanceOutput {}
36 |
37 | /**
38 | * Block Stream data for a `deleteAllowances` transaction.
39 | *
40 | * This message SHALL NOT duplicate information already contained in
41 | * the original transaction.
42 | */
43 | message DeleteAllowanceOutput {}
44 |
45 | /**
46 | * Block Stream data for a `createAccount` transaction.
47 | *
48 | * This message SHALL NOT duplicate information already contained in
49 | * the original transaction.
50 | */
51 | message CreateAccountOutput {
52 | /**
53 | * A newly created account identifier.
54 | * This is the account identifier for the account created as part of
55 | * any transaction that creates a new account.
56 | * This value is necessary due to the difficulty of otherwise identifying
57 | * created accounts versus the other account updates necessary for every
58 | * transaction (e.g. fee payment).
59 | *
60 | * This value SHALL be set for every account creation.
61 | * This value SHALL NOT be set if no account is created.
62 | */
63 | proto.AccountID created_account_id = 1;
64 | }
65 |
66 | /**
67 | * Block Stream data for a `cryptoDelete` transaction.
68 | *
69 | * This message SHALL NOT duplicate information already contained in
70 | * the original transaction.
71 | */
72 | message DeleteAccountOutput {}
73 |
74 | /**
75 | * Block Stream data for a `cryptoTransfer` transaction.
76 | *
77 | * This message SHALL NOT duplicate information already contained in
78 | * the original transaction.
79 | */
80 | message CryptoTransferOutput { }
81 |
82 | /**
83 | * Block Stream data for a `updateAccount` transaction.
84 | *
85 | * This message SHALL NOT duplicate information already contained in
86 | * the original transaction.
87 | */
88 | message UpdateAccountOutput {}
89 |
--------------------------------------------------------------------------------
/HIP/hip-1021.md:
--------------------------------------------------------------------------------
1 | ---
2 | hip: 1021
3 | title: Improve Assignment of Auto-Renew Account ID for Topics
4 | author: Michael Kantor (@kantorcodes)
5 | type: Standards Track
6 | category: Service
7 | status: Final
8 | release: v0.60.0
9 | last-call-date-time: 2024-12-18T07:00:00Z
10 | created: 2024-08-01
11 | requested-by: TierBot
12 | discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/pull/1021
13 | needs-council-approval: Yes
14 | updated: 2024-05-20
15 | ---
16 |
17 | ## Abstract
18 |
19 | This HIP proposes a modification to the Hedera Consensus Service (HCS) to:
20 | - Enable setting the `autoRenewAccountId` when creating a `TopicCreateTransaction` even if an Admin Key is not present during Topic Creation.
21 |
22 |
23 | ## Motivation
24 |
25 | Currently, when a Topic ID is created, the `autoRenewAccountId` is not automatically set to the account that initiated the transaction. Additionally:
26 |
27 | - It is only possible to set this field when an Admin Key is generated with the Topic. For topics that are created with the intention of being more "immutable," this is a risk.
28 | - Up until HIP-874 (https://github.com/hiero-ledger/hiero-improvement-proposals/pull/883/files), it was not easy to verify if a Topic was successfully created with an Autorenew Account Id, leading to more unexpected errors for users.
29 |
30 | This proposal seeks to simplify the process for users by making the auto-renewal mechanism seamless, eliminating the need for Admin Keys to be present when setting the `autoRenewAccountId`.
31 |
32 | ## Rationale
33 |
34 | The proposed change enables expected user interactions with HCS and ensures consistency in managing topic renewals.
35 |
36 | ## Specification
37 |
38 | ### Automatic Setting of autoRenewAccountId in SDKs
39 |
40 | When a new Topic ID is created, the `autoRenewAccountId` shall be automatically set in the SDKs to the account ID that creates the transaction, providing additional flexibility for when an Admin Key is not set.
41 |
42 | ### Backwards Compatibility
43 |
44 | This feature has no issues with backwards compatibility.
45 |
46 | ### Transaction Changes
47 |
48 | The current implementation allows for the `autoRenewAccountId` to be specified during topic creation only when an Admin Key is present. This proposal does not remove this capability, but in the SDKs, adds an automatic default to the transaction creator's account if not explicitly set, and the capability to set an `autoRenewAccountId` even when Admin Key is not present during creation.
49 |
50 | ## Backwards Compatibility
51 |
52 | This feature has no issues with backwards compatibility.
53 |
54 | ## Implementation
55 |
56 | The Hedera node software will be updated to support assignment of the `autoRenewAccountId` during the topic creation process even if an Admin Key is not present.
57 |
58 | ## Drawbacks
59 |
60 | There should be no drawbacks to this approach. Only furture topic ids will be allowed to set `autoRenewAccountId` without needing to also set the Admin Key.
61 |
62 | ## Alternatives
63 |
64 | - **Future Rent Logic Adjustments:** If rent is enabled for TopicId Entities and a Topic Id was created before this HIP, rent would be charged to the `payer_account_id` of the Topic Id when an Autorenew Account Id was not present.
65 |
66 |
--------------------------------------------------------------------------------
/HIP/hip-198.md:
--------------------------------------------------------------------------------
1 | ---
2 | hip: 198
3 | title: Ledger ID
4 | author: Leemon Baird (@lbaird)
5 | type: Informational
6 | needs-council-approval: Yes
7 | status: Accepted
8 | last-call-date-time: 2021-11-22 07:00:00 UTC
9 | created: 2021-11-05
10 | discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/discussions/201
11 | ---
12 |
13 | ## Abstract
14 | This HIP defines a ledger ID that uniquely identifies a particular DLT (Distributed Ledger Technology) network, and maintains a list of ledger IDs for several Hedera ledgers. This will be updated when those IDs change.
15 |
16 | ## Motivation
17 | It is useful to have a cryptographically-secure means to uniquely identify a ledger. This can be used in state proofs that a ledger contains a certain piece of information, such as a given balance for a given account as of a certain date. This ledger ID is not intended to be human readable, but to be machine readable and suitable for cryptographic proofs. For human-readable names for ledgers, see HIP-30.
18 | It is also important to maintain an updated list of such IDs. For the Hedera mainnet, there is currently only a temporary, non-secure ID. It will be replaced with a permanent ID in the new future. When that happens, the new ID will be listed here.
19 |
20 | ## Rationale
21 |
22 | ## Specification
23 | A `ledger ID` is a sequence of 1 or more bytes (255 max), uniquely identifying a single public or private ledger, in a form suitable as a basis for a cryptographic state proof. The following are the current IDs, which are temporary, only a single byte each, and not secure. They will be updated with longer, more secure IDs in the near future. Any software that is written to use ledger IDs should be designed so that it can be updated when the temporary IDs are replaced with permanent IDs.
24 | ```
25 | 0x00 Hedera mainnet
26 | 0x01 Hedera stable testnet
27 | 0x02 Hedera preview net
28 | ```
29 |
30 | ## Backwards Compatibility
31 | All of HIP-15 and HIP-33 and HAPI use the ledger ID. They will use the above byte strings as the values. Software using those ledger IDs will need to change when the above byte strings are changed from their temporary values to their permanent values.
32 |
33 | ## Security Implications
34 | The temporary ledger IDs are not cryptographically secure, but are helpful for avoiding accidental mistakes. When they are replaced with the permanent IDs, they can be used for secure state proofs, and other cryptographically-secure uses.
35 |
36 | ## How to Teach This
37 | Other HIPs and standards should not include copies of the temporary ledger IDs. They should, instead, reference this HIP. Once the temporary IDs are replaced with the permanent IDs, then other standards can start to simply copy them.
38 |
39 | ## Reference Implementation
40 |
41 | ## Rejected Ideas
42 |
43 | ## Open Issues
44 |
45 | ## References
46 | [HIP-15](https://github.com/hiero-ledger/hiero-improvement-proposals/blob/main/HIP/hip-15.md)
47 | [HIP-30](https://github.com/hiero-ledger/hiero-improvement-proposals/blob/main/HIP/hip-30.md)
48 | [HIP-33](https://github.com/hiero-ledger/hiero-improvement-proposals/blob/main/HIP/hip-33.md)
49 |
50 | ## Copyright/license
51 | This document is licensed under the Apache License, Version 2.0 -- see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0)
52 |
--------------------------------------------------------------------------------
/HIP/hip-20.md:
--------------------------------------------------------------------------------
1 | ---
2 | hip: 20
3 | title: Standardized URI scheme to reference Hedera data
4 | author: Khoa Luong , Sam Wood , Stephanie Yi , Declan Fox
5 | type: Standards Track
6 | category: Service
7 | needs-council-approval: Yes
8 | status: Replaced
9 | superseded-by: 30
10 | created: 2021-06-29
11 | discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/discussions/110
12 | ---
13 |
14 | ## Abstract
15 | This HIP defines a way for Hedera to host data in a centralized location and accessible
16 | with a standardized URI.
17 |
18 | ## Motivation
19 |
20 | Non-fungible tokens often have metadata associated with them and this HIP provides a way to
21 | access them with a standardized URI, hosted by Hedera.
22 | Third-party applications would then be able to use this standardized URI to integrate with and
23 | display a token's metadata and image (for example: DECENT Wallet [0]).
24 | Non-Hedera NFT's could also utilize this feature to host their metadata, like ERC-721.
25 |
26 | ## Rationale
27 |
28 | The format of the URI includes the prefix "hcs" to represent that it is hosted on Hedera, and
29 | then the network that the token was deployed on (mainnet/testnet), followed by the topic ID.
30 | Currently, Hedera's ID convention can be confusing because a topic ID on one network can be a
31 | wallet ID in another network, so by using this prefix, we can start standardizing the format of the
32 | IDs. For example, using HCS to distinguish data hosted on Hedera consensus service, HFS prefix for
33 | Hedera file service, as well as including the associated network (testnet, previewnet).
34 |
35 | One use case for the topic ID to be part of the URI is: the metadata of an NFT can be submitted to
36 | this topic as a message and then retrieved by accessing this standardized URI. This gives us an
37 | easy way to send the token's metadata to Hedera without the need for a new API. The token's metadata
38 | URI would then be stored on the memo field of the token when it is deployed.
39 |
40 | ## Specification
41 |
42 | Different Hedera services have different prefixes, for example, HFS for Hedera file service and
43 | HCS for Hedera consensus service.
44 | The URI is in the following format: hcs-:// for testnet and previewnet
45 | and hcs:// for mainnet.
46 | For example: hcs-testnet://0.0.01234. This URI then serve the metadata in the format of the
47 | "Token Metadata JSON Schema", from HIP-10 [1].
48 | For Hedera file service, the format is: hfs:// and hfs-{}://
49 |
50 | ## Backwards Compatibility
51 |
52 | This feature is optional for deployed Hedera tokens so there won't be any backward compatibility
53 | concerns.
54 |
55 | ## Security Implications
56 |
57 | No known security concerns.
58 |
59 | ## How to Teach This
60 |
61 | ## Reference Implementation
62 |
63 | ## Rejected Ideas
64 |
65 | ## Open Issues
66 |
67 | ## References
68 |
69 | [0] https://dcentwallet.com/features/erc721-wallet
70 | [1] https://github.com/hiero-ledger/hiero-improvement-proposals/blob/main/HIP/hip-10.md
71 |
72 | ## Copyright/license
73 |
74 | This document is licensed under the Apache License, Version 2.0 -- see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0)
75 |
--------------------------------------------------------------------------------
/assets/hip-1056/protobuf/stream/input/event_header.proto:
--------------------------------------------------------------------------------
1 | /**
2 | * # Event Header
3 | * This header precedes the event messages that contain transactions.
4 | *
5 | * ### Keywords
6 | * The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
7 | * "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
8 | * document are to be interpreted as described in
9 | * [RFC2119](https://www.ietf.org/rfc/rfc2119) and clarified in
10 | * [RFC8174](https://www.ietf.org/rfc/rfc8174).
11 | */
12 | syntax = "proto3";
13 |
14 | package com.hedera.hapi.block.stream.input;
15 |
16 | // SPDX-License-Identifier: Apache-2.0
17 |
18 | option java_package = "com.hedera.hapi.block.stream.input.protoc";
19 | // <<>> This comment is special code for setting PBJ Compiler java package
20 | option java_multiple_files = true;
21 |
22 |
23 | import "event/event_core.proto";
24 | import "platform/event/event_descriptor.proto";
25 |
26 |
27 | /**
28 | * A header for a single event.
29 | * This message provides information about an event and its parents within a
30 | * block.
31 | *
32 | * An `EventHeader` message that contains only `EventDescriptors` for parents
33 | * can be combined with its following `EventTransaction` messages to create
34 | * a `GossipEvent` message.
35 | * The created `GossipEvent` message can be hashed to create the
36 | * `EventDescriptor` for that event.
37 | * An `EventHeader` that contains indices to parent events within the containing
38 | * block will need to have each parent index replaced by the `EventDescriptor`
39 | * of that parent before it can be translated into a `GossipEvent` message.
40 | */
41 | message EventHeader {
42 | /**
43 | * An event core value.
44 | * This provides information about the event, including its creator.
45 | */
46 | com.hedera.hapi.platform.event.EventCore event_core = 1;
47 |
48 | /**
49 | * A list of references to parent events.
50 | * Each entry can be an `EventDescriptor` or an index to an event
51 | * within the block. These items represent the parents of this event.
52 | *
53 | * This list SHALL include zero or one self parents.
54 | * This list SHALL include zero or more other parents.
55 | * The first element of the list SHALL be the self parent,
56 | * if one exists.
57 | * The list of parents SHALL NOT include more than one parent from the same
58 | * creator.
59 | */
60 | repeated ParentEventReference parents = 2;
61 |
62 | /**
63 | * The middle bit of the node's signature on the event.
64 | *
65 | * This bit SHALL be the middle bit of the node's signature on the hash
66 | * of the event.
67 | */
68 | bool signature_middle_bit = 3;
69 | }
70 |
71 | /*
72 | * A reference to a parent event.
73 | */
74 | message ParentEventReference {
75 |
76 | oneof parent {
77 | /**
78 | * The EventDescriptor of the parent event.
79 | *
80 | * The event referenced SHALL NOT be within the containing block.
81 | */
82 | proto.EventDescriptor descriptor = 1;
83 |
84 | /**
85 | * The index of the parent event.
86 | *
87 | * An `EventHeader`'s index SHALL be the count of preceding `EventHeader`
88 | * and `RoundHeader` block items starting from the beginning of
89 | * the block.
90 | * The index SHALL be zero-based.
91 | */
92 | uint32 index = 2;
93 | }
94 | }
95 |
--------------------------------------------------------------------------------
/HIP/hip-782.md:
--------------------------------------------------------------------------------
1 | ---
2 | hip: 782
3 | title: Smoothing Staking Rewards
4 | author: Leemon Baird
5 | type: Standards Track
6 | category: Core
7 | needs-council-approval: Yes
8 | status: Final
9 | last-call-date-time: 2023-08-09T07:00:00Z"
10 | release: v0.40.0
11 | created: 2023-08-01
12 | discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/pull/782
13 | replaces: 406
14 | updated: 2023-09-13
15 | ---
16 |
17 | Note: This hip does not replace all of hip-406 Staking. It replaces only replaces a small part. Otherwise, hip-406 still stands.
18 |
19 | ## Abstract
20 |
21 | This HIP describes a change to the staking reward system for proof of stake described in HIP-406. HIP-406 gives rewards at a constant reward rate until the unreserved balance of account `0.0.800` is empty, then suddenly drops to a near zero reward rate. This HIP defines a change so that as `0.0.800` approaches being empty, the reward rate decreases smoothly rather than with an abrupt drop.
22 |
23 | ## Motivation
24 |
25 | ## Rationale
26 |
27 | ## User Stories
28 |
29 | ## Specification
30 |
31 | In the original HIP, there is a setting `stakingRewardRate`, and rewards are given at that rate until the unreserved balance of account `0.0.800` is empty, at which point it abruptly drops to simply distributing each day whatever came in to that account the previous day, such as through transaction fees.
32 |
33 | The change is to remove this settings, and have `stakingRewardRate` automatically change each day, based on the balance of `0.0.800` and three settings: `maxRewardRate`, `rewardBalanceThreshold`, and `maxStakeRewarded`. The `maxRewardRate` (in tinybars earned per hbar staked per day) is the rate to pay normally (i.e., when `0.0.800` has a large balance, and not too many hbars are staked for reward). When the balance of `0.0.800` drops below `rewardBalanceThreshold` (in tinybars), then the `stakingRewardRate` drops smoothly as the balance drops. If the hbars staked for reward exceed `maxStakeRewarded` (in tinybars), then there is a further decrease.
34 |
35 | Let `unreservedBalance` (in tinybars) be the balance of account `0.0.800` minus the amount of rewards that have been earned but not yet distributed. Let `stakedForReward` (in tinybars) be the total balance of all accounts on Hedera that have been staked for reward (so it ignores accounts that stake but decline a reward). Then each day, just before the HIP-406 reward calculations are performed using `stakingRewardRate`, recalculate `stakingRewardRate` as follows (implemented with equivalent results, but using integer calculations, rather than the real-number calculations shown):
36 |
37 | ```
38 | //A real number proportional to the unreserved balance, from 0 for empty, up to 1 at the threshold.
39 | balanceRatio = min(unreservedBalance, rewardBalanceThreshold) / rewardBalanceThreshold;
40 |
41 | stakingRewardRate = maxRewardRate
42 | * balanceRatio * (2 – balanceRatio)
43 | * min(1, maxStakeRewarded / stakedForReward)
44 |
45 | ```
46 |
47 | ## Backwards Compatibility
48 |
49 | This has no effect on HAPI or on transactions. It just affects the amount of daily staking rewards received by accounts that stake for reward, when `0.0.800` has a low balance.
50 |
51 | ## Security Implications
52 |
53 | None.
54 |
55 | ## How to Teach This
56 |
57 | ## Reference Implementation
58 |
59 | ## Rejected Ideas
60 |
61 | ## Open Issues / FAQ
62 |
63 | ## Copyright/license
64 |
65 | This document is licensed under the Apache License, Version 2.0 -- see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0)
66 |
--------------------------------------------------------------------------------
/CODE_OF_CONDUCT.md:
--------------------------------------------------------------------------------
1 | # Contributor Covenant Code of Conduct
2 |
3 | ## Our Pledge
4 |
5 | In the interest of fostering an open and welcoming environment, we as
6 | contributors and maintainers pledge to making participation in our project and
7 | our community a harassment-free experience for everyone, regardless of age, body
8 | size, disability, ethnicity, sex characteristics, gender identity and expression,
9 | level of experience, education, socio-economic status, nationality, personal
10 | appearance, race, religion, or sexual identity and orientation.
11 |
12 | ## Our Standards
13 |
14 | Examples of behavior that contributes to creating a positive environment
15 | include:
16 |
17 | * Using welcoming and inclusive language
18 | * Being respectful of differing viewpoints and experiences
19 | * Gracefully accepting constructive criticism
20 | * Focusing on what is best for the community
21 | * Showing empathy towards other community members
22 |
23 | Examples of unacceptable behavior by participants include:
24 |
25 | * The use of sexualized language or imagery and unwelcome sexual attention or
26 | advances
27 | * Trolling, insulting/derogatory comments, and personal or political attacks
28 | * Public or private harassment
29 | * Publishing others' private information, such as a physical or electronic
30 | address, without explicit permission
31 | * Other conduct which could reasonably be considered inappropriate in a
32 | professional setting
33 |
34 | ## Our Responsibilities
35 |
36 | Project maintainers are responsible for clarifying the standards of acceptable
37 | behavior and are expected to take appropriate and fair corrective action in
38 | response to any instances of unacceptable behavior.
39 |
40 | Project maintainers have the right and responsibility to remove, edit, or
41 | reject comments, commits, code, wiki edits, issues, and other contributions
42 | that are not aligned to this Code of Conduct, or to ban temporarily or
43 | permanently any contributor for other behaviors that they deem inappropriate,
44 | threatening, offensive, or harmful.
45 |
46 | ## Scope
47 |
48 | This Code of Conduct applies both within project spaces and in public spaces
49 | when an individual is representing the project or its community. Examples of
50 | representing a project or community include using an official project e-mail
51 | address, posting via an official social media account, or acting as an appointed
52 | representative at an online or offline event. Representation of a project may be
53 | further defined and clarified by project maintainers.
54 |
55 | ## Enforcement
56 |
57 | Instances of abusive, harassing, or otherwise unacceptable behavior may be
58 | reported by contacting the project team at oss@hedera.com. All
59 | complaints will be reviewed and investigated and will result in a response that
60 | is deemed necessary and appropriate to the circumstances. The project team is
61 | obligated to maintain confidentiality with regard to the reporter of an incident.
62 | Further details of specific enforcement policies may be posted separately.
63 |
64 | Project maintainers who do not follow or enforce the Code of Conduct in good
65 | faith may face temporary or permanent repercussions as determined by other
66 | members of the project's leadership.
67 |
68 | ## Attribution
69 |
70 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
71 | available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
72 |
73 | [homepage]: https://www.contributor-covenant.org
74 |
75 | For answers to common questions about this code of conduct, see
76 | https://www.contributor-covenant.org/faq
77 |
--------------------------------------------------------------------------------
/_includes/head.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 |
6 |
7 | {% if page.layout == "hip" %}
8 | HIP-{{ page.hip }}: {{ page.title | escape }}
9 |
10 |
11 |
12 |
13 | {% else %}
14 | {{ page.title | escape }} | {{site.title}}
15 |
19 |
20 |
21 |
22 | {% endif %}
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
31 |
32 |
41 |
42 |
49 |
50 | {%- feed_meta -%}
51 |
52 |
53 |
54 |
55 |
78 |
--------------------------------------------------------------------------------
/HIP/hip-478.md:
--------------------------------------------------------------------------------
1 | ---
2 | hip: 478
3 | title: Interoperability Between Smart Contracts and HCS
4 | author: John Conway (@scalemaildev), Walter Hernandez (@walter-hernandez), Mohsin Qamar (@mohsin-hedera), Michael Garber (@mgarbs), Pathorn Tengkiattrakul (@pathornteng)
5 | type: Standards Track
6 | category: Application
7 | needs-council-approval: No
8 | status: Active
9 | last-call-date-time: 2022-11-15T07:00:00Z
10 | created: 2022-05-17
11 | discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/discussions/479
12 | updated: 2022-11-17
13 | ---
14 |
15 | ## Abstract
16 |
17 | Enable Smart Contracts and Hedera Consensus Services to interoperate by having an oracle network talk to both services. Doing this will allow contracts to create, read, and write to HCS topics via the proxied oracle network.
18 |
19 | ## Motivation
20 |
21 | Interoperability between the HCS and smart contracts via oracle network proxy would enable developers to leverage HCS-stored data in their dApps.
22 |
23 | ## Rationale
24 |
25 | 1. By enabling smart contracts to interact with the HCS via an oracle network proxy, we allow the creation of HCS-based Oracles. For example, an oracle network can talk to a smart contract and also subscribe to a private or public topic in order to read its external data, such as the prices of crypto-assets and give it to the smart contract.
26 |
27 | 2. This would also enable topic-based NFT minting rights. An oracle network could ingest an HCS topic and communicate the result to smart contracts in order to calculate the user's available NFTs. Then, after minting the NFT and transferring it to the user, the smart contract could update that same HCS topic. Currently, this process is only achievable via a centralized, server-based chain of events (such as on [https://hashandslash.io](hashandslash.io)).
28 |
29 | 3. Any other Oracle use case could be repurposed by HCS.
30 |
31 | ## User stories
32 |
33 | As a developer, I want to use a distributed oracle network to read data from HCS topics and send it to my smart contract.
34 |
35 | As a developer, I want to use a distributed oracle network triggered by my smart contract to write to or create HCS topics.
36 |
37 | ## Specification
38 |
39 | 
40 |
41 | ## Security Implications
42 |
43 | With regards to signing transactions from within a smart contract, the main concern is storing private keys in-state. So, some possible solutions are:
44 |
45 | 1. Give a different kind of permission to deployed smart contracts for interacting with certain topics. This could function similarly to how AWS differentiates between key-based permissions and role-based permissions.
46 | 2. Follow the same approach from the [https://hips.hedera.com/hip/hip-206](HTS pre-compiled contracts HIP) to signing transactions and interacting with topics.
47 |
48 | ## Rejected Ideas
49 |
50 | 1. Enable smart contracts to directly interact with HCS topics by following the same approach as the [https://hips.hedera.com/hip/hip-206](HTS pre-compiled contracts HIP). This is not possible since EVM execution must be deterministic. This requires EVM execution to be based on the provable onchain state and signed transactions so there is no way smart contracts can directly call HCS to write to topics.
51 |
52 | 2. Directly reading topics from smart contracts. Although, this is possible, in order to maintain consitency among these kinds of transactions, it is better to read and write through the oracle network.
53 |
54 | ## References
55 |
56 | https://hedera.com/blog/use-cases-for-hcs-based-records-in-play-to-earn-nft-gaming
57 |
58 | https://hashandslash.io
59 |
60 | ## Copyright/license
61 |
62 | This document is licensed under the Apache License, Version 2.0 -- see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0)
63 |
--------------------------------------------------------------------------------
/HIP/hip-874.md:
--------------------------------------------------------------------------------
1 | ---
2 | hip: 874
3 | title: Enhancing Topic Metadata Accessibility in the Hedera REST API
4 | author: Michael Kantor (@kantorcodes), Ty Smith (@ty-swirldslabs)
5 | type: Standards Track
6 | category: Mirror
7 | status: Final
8 | release: v0.106.0
9 | last-call-date-time: 2024-03-27T07:00:00Z
10 | created: 2024-02-14
11 | requested-by: TierBot
12 | discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/pull/883
13 | needs-council-approval: Yes
14 | updated: 2024-06-13
15 | ---
16 |
17 | ## Abstract:
18 | This HIP proposes an enhancement to the Hedera REST API to enable access to topic ID metadata, including the memo field and other relevant entity information. Currently, there is limited direct access to topic metadata through the REST API, which can hinder the development of applications that rely on this data for functionality or auditing purposes. This proposal aims to streamline access to topic metadata, reducing the need for workarounds and enhancing the capabilities of applications built on Hedera.
19 |
20 | ## Motivation:
21 | The ability to access topic ID metadata, including the memo field, submit key, and deleted field directly through the REST API is crucial for a wide range of applications, including messaging, event tracking, and audit-ability functions. Currently, developers may need to employ indirect methods or multiple API calls to retrieve this information, leading to inefficiencies and potential inaccuracies. By providing direct access to this metadata, the proposal seeks to enhance developer experience, reduce computational load, and foster the development of more feature-rich applications on the Hedera platform.
22 |
23 | ## Specification:
24 | The proposed enhancement involves extending the REST API to include a new endpoint to return topic ID metadata, including the memo field and other relevant entity information.
25 |
26 | ### Route:
27 | /api/v1/topics/{topic id}
28 |
29 | Current Response Structure returns:
30 | ```json
31 | {"_status":{"messages":[{"message":"Not found"}]}}
32 | ```
33 |
34 | Proposed Response Structure:
35 | ```json
36 | {
37 | "topic_id": "0.0.123456",
38 | "memo": "[Topic Memo]",
39 | "admin_key": {
40 | "_type": "ED25519",
41 | "key": "bfc9d4a344389324119eed485eb3a875b1e5a54bd189d2fd5ad88ce1d3473dee"
42 | },
43 | "deleted": false,
44 | "submit_key": {
45 | "_type": "ED25519",
46 | "key": "bfc9d4a344389324119eed485eb3a875b1e5a54bd189d2fd5ad88ce1d3473dee"
47 | },
48 | "auto_renew_period": 7890000,
49 | "auto_renew_account": "0.0.654321",
50 | "timestamp" : {
51 | "from: "1707953087.386834512",
52 | "to": null
53 | }
54 | "created_timestamp": "1707953087.386834512"
55 | }
56 | ```
57 |
58 | The addition of these fields will provide comprehensive metadata about topics directly through the API.
59 |
60 | ### Rationale:
61 | Providing direct access to topic ID metadata, including the memo and other relevant information, addresses a critical need for developers building on the Hedera network. This enhancement will facilitate a range of applications, from simple messaging systems to complex, multi-layered applications requiring detailed audit trails. The proposal supports the principles of transparency, efficiency, and developer friendliness that are essential to the Hedera ecosystem.
62 |
63 | ### Backwards Compatibility:
64 | This change is backwards compatible as it would entail the creation of a new API Endpoint. This ensures that existing applications will continue to operate without modification, while new and updated applications can take advantage of the enhanced metadata accessibility.
65 |
66 | ### Security Implications:
67 | The proposal does not introduce significant changes to the security posture of the Hedera API. Access controls and authentication mechanisms remain unchanged, ensuring that the introduction of additional metadata fields does not compromise the integrity or confidentiality of data within the Hedera network.
68 |
--------------------------------------------------------------------------------
/assets/hip-1056/protobuf/stream/output/smart_contract_service.proto:
--------------------------------------------------------------------------------
1 | /**
2 | * # Smart Contract Service
3 | * Block stream messages that report the results of transactions handled
4 | * by the `smart contract` service.
5 | *
6 | * ### Keywords
7 | * The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
8 | * "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
9 | * document are to be interpreted as described in
10 | * [RFC2119](https://www.ietf.org/rfc/rfc2119) and clarified in
11 | * [RFC8174](https://www.ietf.org/rfc/rfc8174).
12 | */
13 | syntax = "proto3";
14 |
15 | package com.hedera.hapi.block.stream.output;
16 |
17 | // SPDX-License-Identifier: Apache-2.0
18 | option java_package = "com.hedera.hapi.block.stream.output.protoc";
19 | // <<>> This comment is special code for setting PBJ Compiler java package
20 | option java_multiple_files = true;
21 |
22 | import "services/contract_types.proto";
23 |
24 | /**
25 | * Block Stream data for a `contractCallMethod` transaction.
26 | *
27 | * This message SHALL NOT duplicate information already contained in
28 | * the original transaction.
29 | */
30 | message CallContractOutput {
31 | /**
32 | * An EVM transaction result. Contains just the information not already
33 | * externalized in the matching transaction body.
34 | */
35 | proto.EvmTransactionResult evm_transaction_result = 1;
36 | }
37 |
38 | /**
39 | * Block Stream data for a `createContract` transaction.
40 | *
41 | * This message SHALL NOT duplicate information already contained in
42 | * the original transaction.
43 | */
44 | message CreateContractOutput {
45 | /**
46 | * An EVM transaction result. Contains just the information not already
47 | * externalized in the matching transaction body.
48 | */
49 | proto.EvmTransactionResult evm_transaction_result = 1;
50 | }
51 |
52 | // no evm exec, only modified entity
53 | /**
54 | * Block Stream data for a `updateContract` transaction.
55 | *
56 | * This message SHALL NOT duplicate information already contained in
57 | * the original transaction.
58 | */
59 | message UpdateContractOutput {}
60 |
61 | // no evm exec, only modified entity
62 | /**
63 | * Block Stream data for a `deleteContract` transaction.
64 | *
65 | * This message SHALL NOT duplicate information already contained in
66 | * the original transaction.
67 | */
68 | message DeleteContractOutput {}
69 |
70 | /**
71 | * Block Stream data for a contract `systemUndelete` transaction.
72 | *
73 | * This message SHALL NOT duplicate information already contained in
74 | * the original transaction.
75 | */
76 | message SystemUnDeleteContractOutput {}
77 |
78 | /**
79 | * Block Stream data for a contract `systemDelete` transaction.
80 | *
81 | * This message SHALL NOT duplicate information already contained in
82 | * the original transaction.
83 | */
84 | message SystemDeleteContractOutput {}
85 |
86 | /**
87 | * Block Stream data for a `callEthereum` transaction.
88 | *
89 | * This message SHALL NOT duplicate information already contained in
90 | * the original transaction.
91 | */
92 | message EthereumOutput {
93 | oneof transaction_result {
94 | /**
95 | * An EVM transaction result for an Ethereum transaction executed as a
96 | * call. Contains just the information not already externalized in the
97 | * matching transaction body.
98 | */
99 | proto.EvmTransactionResult evm_call_transaction_result = 1;
100 |
101 | /**
102 | * An EVM transaction result for an Ethereum transaction executed as a
103 | * create. Contains just the information not already externalized in the
104 | * matching transaction body.
105 | */
106 | proto.EvmTransactionResult evm_create_transaction_result = 2;
107 | }
108 | }
109 |
110 |
--------------------------------------------------------------------------------
/assets/hip-1056/protobuf/stream/output/block_header.proto:
--------------------------------------------------------------------------------
1 | /**
2 | * # Block Header
3 | * The block header reports information required to correctly process a block.
4 | * This includes versions, block number, and algorithms used.
5 | *
6 | * ### Keywords
7 | * The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
8 | * "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
9 | * document are to be interpreted as described in
10 | * [RFC2119](https://www.ietf.org/rfc/rfc2119) and clarified in
11 | * [RFC8174](https://www.ietf.org/rfc/rfc8174).
12 | */
13 | syntax = "proto3";
14 |
15 | package com.hedera.hapi.block.stream.output;
16 |
17 | // SPDX-License-Identifier: Apache-2.0
18 |
19 | option java_package = "com.hedera.hapi.block.stream.output.protoc";
20 | // <<>> This comment is special code for setting PBJ Compiler java package
21 | option java_multiple_files = true;
22 |
23 | import "basic_types.proto";
24 | import "timestamp.proto";
25 |
26 | /**
27 | * A Block Header.
28 | *
29 | * Each block in the block stream SHALL begin with a block header.
30 | * The block header SHALL provide the base minimum information needed to
31 | * correctly interpret and process that block, or stop processing
32 | * if appropriate.
33 | * The block header MUST describe, at minimum, the following items.
34 | * - The version of the block stream data
35 | * - The block number
36 | * - The hash of the previous block
37 | * - The hash algorithm used to generate the block hash
38 | *
39 | * All fields of this message are REQUIRED, with the exception that
40 | * `hash_algorithm` MAY be _transmitted_ as a default value to improve
41 | * data efficiency.
42 | */
43 | message BlockHeader {
44 | /**
45 | * A version of the HAPI specification.
46 | * This is the API version that was used to serialize the block.
47 | */
48 | proto.SemanticVersion hapi_proto_version = 1;
49 |
50 | /**
51 | * A version of the consensus node software.
52 | * This is the software version that executed the transactions
53 | * within this block.
54 | */
55 | proto.SemanticVersion software_version = 2;
56 |
57 | /**
58 | * A block number for this block.
59 | *
60 | * This value MUST be exactly `1` more than the previous block.
61 | * Client systems SHOULD optimistically reject any block with a gap or
62 | * reverse in `number` sequence, and MAY assume the block stream has
63 | * encountered data loss, data corruption, or unauthorized modification.
64 | */
65 | uint64 number = 3;
66 |
67 | /**
68 | * The timestamp for this block.
69 | * The block timestamp is the consensus time stamp of the first round
70 | * in the block.
71 | *
72 | * This SHALL be a timestamp for the block, determined as follows:
73 | * Given the first round within a block
74 | *
75 | *
If the round contains events and transactions, the
76 | * timestamp SHALL be the timestamp of the last transaction in
77 | * the round.
78 |
If the round has events but no transactions the timestamp
79 | * SHALL be the timestamp of the last event in the round.
80 | *
If the round contains no events or transactions, the
81 | * timestamp SHALL be the timestamp of the previous round plus
82 | * 1000 nanoseconds.
83 | *
If the round contains no events or transactions and there
84 | * is no previous round, the timestamp SHALL be the median of
85 | * the judge created timestamps for this round.
86 | *
87 | */
88 | proto.Timestamp block_timestamp = 4;
89 |
90 | /**
91 | * A hash algorithm used for this block, including the block proof.
92 | *
93 | * This SHOULD always be `SHA2_384`, currently.
94 | */
95 | proto.BlockHashAlgorithm hash_algorithm = 5;
96 | }
97 |
--------------------------------------------------------------------------------
/assets/hip-1056/protobuf/stream/record_file_item.proto:
--------------------------------------------------------------------------------
1 | /**
2 | * # Record File Block
3 | * This block carries the data from "record stream" and "sidecar"
4 | * files that preceded the block stream. Record blocks are full blocks,
5 | * not block items, but do not have a block header or block proof.
6 | *
7 | * ### Keywords
8 | * The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
9 | * "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
10 | * document are to be interpreted as described in
11 | * [RFC2119](https://www.ietf.org/rfc/rfc2119) and clarified in
12 | * [RFC8174](https://www.ietf.org/rfc/rfc8174).
13 | */
14 | syntax = "proto3";
15 |
16 | package com.hedera.hapi.block.stream;
17 |
18 | // SPDX-License-Identifier: Apache-2.0
19 |
20 | option java_package = "com.hedera.hapi.block.stream.protoc";
21 | // <<>> This comment is special code for setting PBJ Compiler java package
22 | option java_multiple_files = true;
23 |
24 | import "basic_types.proto";
25 | import "timestamp.proto";
26 |
27 | /**
28 | * A Block Item for record files.
29 | *
30 | * A `RecordFileItem` contains data produced before the innovation of the
31 | * Block Stream, when data was stored in files and validated by individual
32 | * signature files rather than a block proof.
33 | * This item enables a single format, the Block Stream, to carry both
34 | * historical and current data; eliminating the need to search two sources for
35 | * block and block chain data.
36 | * Any block containing this item requires special handling.
37 | * - The block SHALL have a `BlockHeader`.
38 | * - Some fields in the `BlockHeader` may be interpreted differently, and
39 | * may depend on when the original record file was created.
40 | * - The block SHALL NOT have a `BlockProof`.
41 | * - The block SHALL end with an `AddressBookProof`, which is only used for
42 | * `RecordFileItem` blocks.
43 | * - The block SHALL contain _exactly one_ `RecordFileItem`.
44 | * - The block SHALL NOT contain any content item other than a `RecordFileItem`.
45 | * - The content of the `RecordFileItem` MUST be validated using the
46 | * signature data and content provided herein according to the
47 | * process used for Record Files prior to the creation of Block Stream.
48 | * - This block item only replaces the requirement to read several
49 | * individual files from cloud storage services.
50 | * - The address book relevant to a particular record file SHALL be available
51 | * separately as an `AddressBookProof` item.
52 | */
53 | message RecordFileItem {
54 | /**
55 | * The consensus time the record file was produced for.
56 | * This comes from the record file name.
57 | */
58 | proto.Timestamp creation_time = 1;
59 |
60 | /**
61 | * The contents of a record file.
62 | * The first 4 bytes are a 32bit int little endian version number.
63 | * The versions that existed are 2,3,5 and 6.
64 | */
65 | bytes record_file_contents = 2;
66 |
67 | /**
68 | * The contents of sidecar files for this block.
69 | * Each block can have zero or more sidecar files.
70 | */
71 | repeated proto.SidecarFile sidecar_file_contents = 3;
72 |
73 | /**
74 | * A collection of RSA signatures from consensus nodes.
75 | * These signatures validate the hash of the record_file_contents field.
76 | */
77 | repeated RecordFileSignature record_file_signatures = 4;
78 | }
79 |
80 | /**
81 | * A signature by a node on the SHA384 hash of the record file.
82 | */
83 | message RecordFileSignature {
84 | /**
85 | * A single RSA signature.
86 | * This is the RSA signature of the node on the SHA384 hash of
87 | * the record file
88 | */
89 | bytes signatures_bytes = 1;
90 |
91 | /**
92 | * A unique node identifier.
93 | * This is the node id of the consensus node that created this signature.
94 | */
95 | int32 node_id = 2;
96 | }
97 |
--------------------------------------------------------------------------------
/assets/hip-206/solidity/FeeHelper.sol:
--------------------------------------------------------------------------------
1 | // SPDX-License-Identifier: Apache-2.0
2 | pragma solidity >=0.5.0 <0.9.0;
3 | pragma experimental ABIEncoderV2;
4 |
5 | import "./HederaTokenService.sol";
6 | import "./HederaResponseCodes.sol";
7 | import "./IHederaTokenService.sol";
8 | import "./KeyHelper.sol";
9 |
10 | contract FeeHelper is KeyHelper {
11 |
12 | function createFixedHbarFee(
13 | uint32 amount,
14 | address feeCollector
15 | ) internal pure returns (IHederaTokenService.FixedFee memory fixedFee) {
16 | fixedFee.amount = amount;
17 | fixedFee.useHbarsForPayment = true;
18 | fixedFee.feeCollector = feeCollector;
19 | }
20 |
21 | function createFixedTokenFee(
22 | uint32 amount,
23 | address tokenId,
24 | address feeCollector
25 | ) internal pure returns (IHederaTokenService.FixedFee memory fixedFee) {
26 | fixedFee.amount = amount;
27 | fixedFee.tokenId = tokenId;
28 | fixedFee.feeCollector = feeCollector;
29 | }
30 |
31 | function createFixedSelfDenominatedFee(
32 | uint32 amount,
33 | address feeCollector
34 | ) internal pure returns (IHederaTokenService.FixedFee memory fixedFee) {
35 | fixedFee.amount = amount;
36 | fixedFee.useCurrentTokenForPayment = true;
37 | fixedFee.feeCollector = feeCollector;
38 | }
39 |
40 | function createFractionalFee(
41 | uint32 numerator,
42 | uint32 denominator,
43 | bool netOfTransfers,
44 | address feeCollector
45 | ) internal pure returns (IHederaTokenService.FractionalFee memory fractionalFee) {
46 | fractionalFee.numerator = numerator;
47 | fractionalFee.denominator = denominator;
48 | fractionalFee.netOfTransfers = netOfTransfers;
49 | fractionalFee.feeCollector = feeCollector;
50 | }
51 |
52 | function createFractionalFeeWithMinAndMax(
53 | uint32 numerator,
54 | uint32 denominator,
55 | uint32 minimumAmount,
56 | uint32 maximumAmount,
57 | bool netOfTransfers,
58 | address feeCollector
59 | ) internal pure returns (IHederaTokenService.FractionalFee memory fractionalFee) {
60 | fractionalFee.numerator = numerator;
61 | fractionalFee.denominator = denominator;
62 | fractionalFee.minimumAmount = minimumAmount;
63 | fractionalFee.maximumAmount = maximumAmount;
64 | fractionalFee.netOfTransfers = netOfTransfers;
65 | fractionalFee.feeCollector = feeCollector;
66 | }
67 |
68 | function createRoyaltyFeeWithoutFallback(
69 | uint32 numerator,
70 | uint32 denominator,
71 | address feeCollector
72 | ) internal pure returns (IHederaTokenService.RoyaltyFee memory royaltyFee) {
73 | royaltyFee.numerator = numerator;
74 | royaltyFee.denominator = denominator;
75 | royaltyFee.feeCollector = feeCollector;
76 | }
77 |
78 | function createRoyaltyFeeWithHbarFallbackFee(
79 | uint32 numerator,
80 | uint32 denominator,
81 | uint32 amount,
82 | address feeCollector
83 | ) internal pure returns (IHederaTokenService.RoyaltyFee memory royaltyFee) {
84 | royaltyFee.numerator = numerator;
85 | royaltyFee.denominator = denominator;
86 | royaltyFee.amount = amount;
87 | royaltyFee.useHbarsForPayment = true;
88 | royaltyFee.feeCollector = feeCollector;
89 | }
90 |
91 | function createRoyaltyFeeWithTokenDenominatedFallbackFee(
92 | uint32 numerator,
93 | uint32 denominator,
94 | uint32 amount,
95 | address tokenId,
96 | address feeCollector
97 | ) internal pure returns (IHederaTokenService.RoyaltyFee memory royaltyFee) {
98 | royaltyFee.numerator = numerator;
99 | royaltyFee.denominator = denominator;
100 | royaltyFee.amount = amount;
101 | royaltyFee.tokenId = tokenId;
102 | royaltyFee.feeCollector = feeCollector;
103 | }
104 | }
--------------------------------------------------------------------------------
/assets/hip-1081/protobuf/node_service.proto:
--------------------------------------------------------------------------------
1 | // SPDX-License-Identifier: Apache-2.0
2 | syntax = "proto3";
3 |
4 | package org.hiero.block.api;
5 |
6 | option java_package = "org.hiero.block.api.protoc";
7 | // <<>> This comment is special code for setting PBJ Compiler java package
8 | option java_multiple_files = true;
9 |
10 | import "services/basic_types.proto";
11 |
12 | /**
13 | * A request for the status of a Block-Node.
14 | */
15 | message ServerStatusRequest {}
16 |
17 | /**
18 | * A response to a server status request.
19 | *
20 | * This message SHALL provide a client with information needed to successfully
21 | * query this Block-Node for a block, stream of blocks, or
22 | * state snapshot.
23 | * A request for blocks between `first_available_block` and
24 | * `last_available_block`, inclusive, SHOULD succeed. Any request for blocks
25 | * outside that range SHOULD fail.
26 | */
27 | message ServerStatusResponse {
28 | /**
29 | * The lowest numbered block available on this Block-Node.
30 | *
31 | * Any request for a block with lower number than this value SHALL fail
32 | * with a status value indicating and invalid start block number.
33 | */
34 | uint64 first_available_block = 1;
35 |
36 | /**
37 | * The greatest block number available from this Block-Node.
38 | *
39 | * Any request for a block with a block number higher than this
40 | * value MAY fail.
41 | */
42 | uint64 last_available_block = 2;
43 |
44 | /**
45 | * A flag indicating this Block-Node only offers the latest state snapshot.
46 | *
47 | * If this value is `true` the client MUST set `retrieve_latest` `true`
48 | * in any `StateSnapshotRequest` sent to this Block-Node.
49 | */
50 | bool only_latest_state = 3;
51 |
52 | /**
53 | * Version information.
54 | * Versions for the block network address book, block stream protocol
55 | * buffer schema, and Block-Node software.
56 | */
57 | BlockNodeVersions version_information = 4;
58 | }
59 |
60 | /**
61 | * Version information for a Block-Node.
62 | *
63 | * The `stream_proto_version` SHOULD be an officially released Block Stream
64 | * version.
65 | * The `address_book_version` SHALL be determined by networks of Block-Nodes.
66 | * The `software_version` SHALL be determined by the implementation of this
67 | * specification.
68 | */
69 | message BlockNodeVersions {
70 | /**
71 | * A version of the Block-Node network address book.
72 | * The address book version describes what version of address book
73 | * this Block-Node holds for discovering and identifying other Block-Nodes.
74 | *
75 | * This version SHALL be specific to each "network" of interconnected
76 | * Block-Nodes.
77 | */
78 | proto.SemanticVersion address_book_version = 1;
79 |
80 | /**
81 | * A version of the Block Stream specification.
82 | * This is the Stream version currently supported by this Block-Node.
83 | *
84 | * Implementations SHOULD make reasonable effort to ensure the latest
85 | * released Block Stream version is supported.
86 | * This version MUST be an officially released Block Stream version if
87 | * the responding Block-Node is not private.
88 | */
89 | proto.SemanticVersion stream_proto_version = 2;
90 |
91 | /**
92 | * A version of the Block-Node software.
93 | * This is the software version that this Block-Node is currently
94 | * running.
95 | *
96 | * This value is implementation-defined.
97 | */
98 | proto.SemanticVersion software_version = 3;
99 | }
100 |
101 | /**
102 | * Remote procedure calls (RPCs) for the Block-Node ancillary services.
103 | */
104 | service BlockNodeService {
105 | /**
106 | * Read the status of this Block-Node.
107 | *
108 | * A client SHOULD request server status prior to requesting block stream
109 | * data or a state snapshot.
110 | */
111 | rpc serverStatus(ServerStatusRequest) returns (ServerStatusResponse);
112 | }
113 |
--------------------------------------------------------------------------------
/_includes/toc.html:
--------------------------------------------------------------------------------
1 | {% capture tocWorkspace %}
2 | {% comment %}
3 | Version 1.0.10
4 | https://github.com/allejo/jekyll-toc
5 |
6 | "...like all things liquid - where there's a will, and ~36 hours to spare, there's usually a/some way" ~jaybe
7 |
8 | Usage:
9 | {% include toc.html html=content sanitize=true class="inline_toc" id="my_toc" h_min=2 h_max=3 %}
10 |
11 | Parameters:
12 | * html (string) - the HTML of compiled markdown generated by kramdown in Jekyll
13 |
14 | Optional Parameters:
15 | * sanitize (bool) : false - when set to true, the headers will be stripped of any HTML in the TOC
16 | * class (string) : '' - a CSS class assigned to the TOC
17 | * id (string) : '' - an ID to assigned to the TOC
18 | * h_min (int) : 1 - the minimum TOC header level to use; any header lower than this value will be ignored
19 | * h_max (int) : 6 - the maximum TOC header level to use; any header greater than this value will be ignored
20 | * ordered (bool) : false - when set to true, an ordered list will be outputted instead of an unordered list
21 | * item_class (string) : '' - add custom class(es) for each list item; has support for '%level%' placeholder, which is the current heading level
22 | * baseurl (string) : '' - add a base url to the TOC links for when your TOC is on another page than the actual content
23 | * anchor_class (string) : '' - add custom class(es) for each anchor element
24 |
25 | Output:
26 | An ordered or unordered list representing the table of contents of a markdown block. This snippet will only
27 | generate the table of contents and will NOT output the markdown given to it
28 | {% endcomment %}
29 |
30 | {% capture my_toc %}{% endcapture %}
31 | {% assign orderedList = include.ordered | default: false %}
32 | {% assign minHeader = include.h_min | default: 1 %}
33 | {% assign maxHeader = include.h_max | default: 6 %}
34 | {% assign nodes = include.html | split: ' maxHeader %}
47 | {% continue %}
48 | {% endif %}
49 |
50 | {% if firstHeader %}
51 | {% assign firstHeader = false %}
52 | {% assign minHeader = headerLevel %}
53 | {% endif %}
54 |
55 | {% assign indentAmount = headerLevel | minus: minHeader %}
56 | {% assign _workspace = node | split: '' | first }}>{% endcapture %}
71 | {% assign header = _workspace[0] | replace: _hAttrToStrip, '' %}
72 |
73 | {% assign space = '' %}
74 | {% for i in (1..indentAmount) %}
75 | {% assign space = space | prepend: ' ' %}
76 | {% endfor %}
77 |
78 | {% if include.item_class and include.item_class != blank %}
79 | {% capture listItemClass %}{:.{{ include.item_class | replace: '%level%', headerLevel }}}{% endcapture %}
80 | {% endif %}
81 |
82 | {% capture heading_body %}{% if include.sanitize %}{{ header | strip_html }}{% else %}{{ header }}{% endif %}{% endcapture %}
83 | {% capture my_toc %}{{ my_toc }}
84 | {{ space }}{{ listModifier }} {{ listItemClass }} [{{ heading_body | replace: "|", "\|" }}]({% if include.baseurl %}{{ include.baseurl }}{% endif %}#{{ html_id }}){% if include.anchor_class %}{:.{{ include.anchor_class }}}{% endif %}{% endcapture %}
85 | {% endfor %}
86 |
87 | {% if include.class and include.class != blank %}
88 | {% capture my_toc %}{:.{{ include.class }}}
89 | {{ my_toc | lstrip }}{% endcapture %}
90 | {% endif %}
91 |
92 | {% if include.id %}
93 | {% capture my_toc %}{: #{{ include.id }}}
94 | {{ my_toc | lstrip }}{% endcapture %}
95 | {% endif %}
96 | {% endcapture %}{% assign tocWorkspace = '' %}{{ my_toc | markdownify | strip }}
97 |
--------------------------------------------------------------------------------
/HIP/hip-1008.md:
--------------------------------------------------------------------------------
1 | ---
2 | hip: 1008
3 | title: Enhance Mirror Node Contract Log REST API with transaction hash query parameter
4 | author: Georgi Lazarov
5 | working-group: Steven Sheehy <@steven-sheehy>, Nana Essilfie-Conduah , Xin Li <@xin-hedera>
6 | type: Standards Track
7 | category: Mirror
8 | needs-council-approval: Yes
9 | status: Final
10 | release: v0.110.2
11 | last-call-date-time: 2024-08-08T07:00:00Z
12 | created: 2024-07-12
13 | requested-by: ChainLink
14 | discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/discussions/1007
15 | updated: 2024-08-08
16 | ---
17 |
18 | ## Abstract
19 |
20 | This HIP provides the capability of querying contract logs by transaction hash in Mirror Node REST API and getting the corresponding logs information.
21 |
22 | ## Motivation
23 |
24 | To enhance user experience and allow ethereum tools, such as Hardhat and MetaMask to be able retrieve information in the form of transaction receipts for HTS operations, like transfer and approve. In order for this information to be available, we’d need to add this functionality to the mirror node to support querying contract logs by transaction hash. This is very common use case across other tools as well, like The Graph.
25 |
26 | ## Rationale
27 |
28 | Every time a tool, like Hardhat sends a transaction, all they get back is the transaction hash. In an automated scenario, like a dapp flow, this hash is not enough to get the transaction receipt for HTS operation. All information about those operations in form of events is stored in the contract logs route. Enabling querying by transaction hash will allow constructing those transaction receipts in the json-rpc-relay and returning them to the requester.
29 |
30 | ## User Stories
31 |
32 | - As a user of mirror node, I want to be able to query using transaction hash and get the corresponding contract log.
33 | - As a user of ethereum tools, I want to be able to request transaction receipt using `eth_getTransactionReceipt` and get corresponding HTS operation transaction receipt.
34 |
35 | ## Specification
36 |
37 | The proposed enhancement involves adding query parameter `transaction.hash` to the existing route `/api/v1/contracts/results/logs` to return information about the contract log.
38 |
39 | ### Transaction Hash Parameter
40 |
41 | A new `transaction.hash` parameter will be added to search for contracts logs by their hash. This transaction hash query parameter should be in hex format with optional leading `0x` prefix and will support both 32 byte Ethereum and 48 byte Hedera transaction hashes.
42 |
43 | **`/api/v1/contracts/results/logs?transaction.hash={value}`**
44 |
45 | **Example Request**
46 |
47 | `/api/v1/contracts/results/logs?transaction.hash=0xda1aee3c386763b2cb2e830765053e346d11deff1c343a5fefe84910f9dfe63b`
48 |
49 | Note: if `limit` is not specified in the request, the response will be limited to 25 by default.
50 |
51 | **Response**
52 |
53 | ```json
54 | {
55 | "logs": [
56 | {
57 | "address": "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
58 | "bloom": "0x549358c4c2e573e02410ef7b5a5ffa5f36dd7398",
59 | "contract_id": "0.0.2",
60 | "data": "0x00000000000000000000000000000000000000000000000000000000000000fa",
61 | "index": 0,
62 | "topics": [
63 | "0xf4757a49b326036464bec6fe419a4ae38c8a02ce3e68bf0809674f6aab8ad300"
64 | ],
65 | "block_hash": "0x553f9311833391c0a3b2f9ed64540a89f2190a511986cd94889f1c0cf7fa63e898b1c6730f14a61755d1fb4ca05fb073",
66 | "block_number": 10,
67 | "root_contract_id": "0.0.2",
68 | "timestamp": "1586567700.453054000",
69 | "transaction_hash": "0xda1aee3c386763b2cb2e830765053e346d11deff1c343a5fefe84910f9dfe63b",
70 | "transaction_index": 1
71 | }
72 | ],
73 | "links": {
74 | "next": null
75 | }
76 | }
77 | ```
78 |
79 | ## Backwards Compatibility
80 |
81 | The change is backwards compatible as it is simply adding one query parameter to an existing route. The data required to filter by transaction hash is already stored in the mirror node.
82 |
83 | ## Rejected Ideas
84 |
85 | None
86 |
87 | ## References
88 |
89 | https://mainnet.mirrornode.hedera.com/api/v1/docs/#/contracts/getContractsLogs
90 |
91 | ## Copyright/License
92 |
93 | This document is licensed under the Apache License, Version 2.0 – see [LICENSE](https://www.notion.so/LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0)
94 |
--------------------------------------------------------------------------------
/HIP/hip-865.md:
--------------------------------------------------------------------------------
1 | ---
2 | hip: 865
3 | title: Add EVM Support for transient storage and memory copy Cancun opcodes
4 | author: Danno Ferrin (@shemnon)
5 | working-group: Nana Essilfie-Conduah <@nana-ec>
6 | requested-by: EVM Developers
7 | type: Standards Track
8 | category: Core
9 | needs-council-approval: Yes
10 | status: Final
11 | release: 0.50.1
12 | last-call-date-time: 2024-03-06T07:00:00Z
13 | created: 2024-01-24
14 | discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/discussions/872
15 | updated: 2024-06-24
16 | ---
17 |
18 | ## Abstract
19 |
20 | Update the Hedera network to add support for new Opcodes found in the Cancun
21 | fork of
22 | Ethereum Mainnet unrelated to EIP-4844 support, namely TSTORE, TLOAD, and MCOPY
23 |
24 | ## Motivation
25 |
26 | Hedera's goal of EVM Equivalence also includes the requirement to stay
27 | up-to-date with the current state of Ethereum Mainnet. This HIP addresses new
28 | opcodes added to the EVM that do not address any features relating to Blobs, or
29 | the Consensus Layer, or changes to existing opcodes.
30 |
31 | ## Rationale
32 |
33 | The opcodes discussed in this HIP only exist within the EVM and do not interact
34 | with any novel features of ethereum mainnet (such as blobs and CL beacon root).
35 | The current version of Solidity may generate these opcodes with non-standard CLI
36 | options. It is expected in the near future those options will be defaults. Other
37 | languages are expected to follow a similar path with eventual implicit and
38 | explicit use of these opcodes. Because of that we need to support them as
39 | specified.
40 |
41 | ## User stories
42 |
43 | * As a smart contract author, I want to be able to use transient storage
44 | features of solidity in my hedera smart contracts.
45 | * As a smart contract author, I want to be able to use future versions of
46 | Solidity, Vyper, Fe, et al. that may use memory copying implicitly.
47 | * As a smart contract author, I want to be able to explicitly use the memory
48 | copy features solidity may expose in future releases.
49 |
50 | ## Specification
51 |
52 | ### EVM Implementation
53 |
54 | Two EIPs define the operational semantics of the added opcodes. For the
55 | transient storage opcodes `TSTORE` and `TLOAD` they are defined
56 | in [EIP-1153](https://eips.ethereum.org/EIPS/eip-1153). For the `MCOPY`
57 | operation they are defined
58 | in [EIP-5656](https://eips.ethereum.org/EIPS/eip-5656).
59 |
60 | The specified opcodes are to be implemented identically to Ethereum Mainnet and
61 | as specified in their respective EIPs. This includes opcode numbers, gas
62 | schedules, stack semantics, and new facilities such as transient storage added
63 | to the execution frame.
64 |
65 | ## Backwards Compatibility
66 |
67 | The core EVM library shipping with Hedera as of version 0.46 already contains
68 | the needed EVM support. The activation will add a new Hedera EVM version that
69 | will activate all the Cancun support in one release.
70 |
71 | ## Security Implications
72 |
73 | Because the operations are being brought in with identical semantics there are
74 | no security risks above those already present from existing Ethereum Equivalence
75 | changes.
76 |
77 | ## How to Teach This
78 |
79 | Any smart contract tutorials will want to examine the possibility of adding
80 | sample contracts showcasing the use of transient storage and easy memory
81 | copying. Ideally these could be sourced from existing Ethereum Tutorials as the
82 | features are fairly well anticipated in the Ethereum community.
83 |
84 | ## Reference Implementation
85 |
86 | // TBD
87 |
88 | ## Rejected Ideas
89 |
90 | No ideas were rejected around these three opcodes, aside from not supporting
91 | Cancun features.
92 |
93 | The idea of supporting [EIP-4788](https://eips.ethereum.org/EIPS/eip-4788):
94 | Beacon block root in the EVM was rejected because there is no EL/CL separation
95 | in Hedera. If we wanted to support similar hash storage ideas we would want to
96 | mine a different address.
97 |
98 | ## Open Issues
99 |
100 | // none
101 |
102 | ## References
103 |
104 | * [EIP-1153](https://eips.ethereum.org/EIPS/eip-1153): Transient storage opcodes
105 | * [EIP-5656](https://eips.ethereum.org/EIPS/eip-5656): MCOPY - Memory copying
106 | instruction
107 |
108 | ## Copyright/license
109 |
110 | This document is licensed under the Apache License, Version 2.0 --
111 | see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0)
112 |
--------------------------------------------------------------------------------
/HIP/hip-968.md:
--------------------------------------------------------------------------------
1 | ---
2 | hip: 968
3 | title: Enhance mirror node rest API to query by token name
4 | author: Simi Hunjan , Ali Nikan <@alinik4n>
5 | working-group: Steven Sheehy <@steven-sheehy>, Eric , Simon
6 | type: Standards Track
7 | category: Mirror
8 | needs-council-approval: Yes
9 | status: Final
10 | release: v0.110.2
11 | last-call-date-time: 2024-06-03T07:00:00Z
12 | created: 2024-04-19
13 | requested-by: Hashport, Bonzo Finance
14 | discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/pull/968
15 | updated: 2024-08-08
16 | ---
17 |
18 | ## Abstract
19 |
20 | This HIP provides the capability of querying tokens by token name in mirror node REST API and getting the corresponding token ID information.
21 |
22 | ## Motivation
23 |
24 | To enhance user experience and allow blockchain explorers such as Hashscan to enable the capability of searching by token name, we want to add this functionality to the mirror node to support querying tokens by token name.
25 | This is a very common use case across other explorers in the larger ecosystem, and will allow retail users and developers to be able to search for a token by token name instead of token ID.
26 |
27 | ## Rationale
28 |
29 | Many times a user may not know the exact token ID when searching for a token, but they know the name. This capability allow users to search by the name and will return results when there is a partial match or exact match. Community members from bridges, Dexes, etc. have been requesting for this for a while.
30 |
31 | ## User stories
32 |
33 | - As a user of mirror node, I want to be able to query with a token name (e.g Sauce) and get the corresponding token ID and information.
34 | - As a user of mirror node, I want to be able to see full match and partial match to my search. (e.g when querying for Sauce, I want to see result for $sauce and $xsauce)
35 | - As a user of a Hedera explorer, I want to look up a token by searching for token name.
36 |
37 | ## Specification
38 |
39 | The proposed enhancement involves adding query parameters `name` to the existing route `/api/v1/tokens` to return information about a token. This new capability only supports HTS tokens at this point and will not include ERC 20/721 tokens, further improvements will be introduced later to support ERC 20/721.
40 |
41 | **Multiple Query Results**
42 |
43 | Names assigned to tokens when tokens are created on the network are not unique. Therefore, many tokens with the same name can exist. Querying a token by a given name will return all the tokens that have the specified name defined in the token name.
44 |
45 | **Name Query Parameter**
46 |
47 | A new `name` query parameter will be added to search for tokens by their name. This query parameter will perform a case insensitive sub-string match. That is, it will search for token names that start with, contain, or end with the given value. The usual operators like `eq`, `gt`, `gte`, `lt, `lte`, and `ne` will not be supported.
48 |
49 | `/api/v1/tokens?name={value}`
50 |
51 |
52 | **Request**
53 | ```
54 | /api/v1/tokens?name=exampleToken
55 | ```
56 | **Example Request**
57 |
58 | ```
59 | GET /api/v1/tokens?limit=2&name=sauce
60 | ```
61 | Note: if ```limit``` is not specified in the request, response will be limited to 25 by default
62 |
63 | **Response**
64 | Note: Most fields omitted for brevity
65 |
66 | ```json
67 | {
68 | "tokens": [{
69 | "name": "SAUCE",
70 | "symbol": "SAUCE",
71 | "token_id": "0.0.731861"
72 | }, {
73 | "name": "xSAUCE",
74 | "symbol": "XSAUCE",
75 | "token_id": "0.0.1460200"
76 | }
77 | ],
78 | "links": {
79 | "next": "/api/v1/tokens?limit=2&name=sauce&token.id=gt:0.0.1460200"
80 | }
81 | }
82 | ```
83 |
84 | ## **Backwards Compatibility**
85 |
86 | The change is backwards compatible as it is simply adding two query parameters to an existing route. The data required to filter by name is already stored in the mirror node.
87 |
88 | ## Security Implications
89 |
90 | Full text search indices can slow down ingest performance if the same lexeme shows up in many token names.
91 |
92 | ## Rejected Ideas
93 |
94 | - Searching token by symbol.
95 |
96 | ## References
97 |
98 | https://mainnet-public.mirrornode.hedera.com/api/v1/docs/#/tokens/listTokens
99 |
100 | ## Copyright/license
101 |
102 | This document is licensed under the Apache License, Version 2.0 -- see [LICENSE](https://www.notion.so/LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0)
103 |
--------------------------------------------------------------------------------
/assets/hip-1081/protobuf/state_service.proto:
--------------------------------------------------------------------------------
1 | // SPDX-License-Identifier: Apache-2.0
2 | syntax = "proto3";
3 |
4 | package org.hiero.block.api;
5 |
6 | option java_package = "org.hiero.block.api.protoc";
7 | // <<>> This comment is special code for setting PBJ Compiler java package
8 | option java_multiple_files = true;
9 |
10 | /**
11 | * A request to read a state snapshot.
12 | *
13 | * A state snapshot is a full copy of the network state at the completion of a
14 | * particular block.
15 | *
16 | * This request MUST contain a block number that has already reached this block
17 | * node and completed verification, or request the "latest" snapshot.
18 | * This request MAY specify the "latest" snapshot, and the block node SHALL
19 | * respond with a reference to a snapshot containing the most recent contents
20 | * of the network state known to that block node.
21 | */
22 | message StateSnapshotRequest {
23 | /**
24 | * A block number.
25 | *
26 | * This SHALL be the last block number present in the snapshot
27 | * returned.
28 | * If `retrieve_latest` is set `true` this field SHOULD NOT be set
29 | * and SHALL be ignored.
30 | * A block node implementation MAY reject any request with a non-default
31 | * value for this field, but MUST clearly document that behavior.
32 | */
33 | uint64 last_block_number = 1;
34 |
35 | /**
36 | * A boolean to request the latest available snapshot.
37 | *
38 | * This value MAY be set `true` to request the most recent state snapshot
39 | * available.
40 | * If this value is set to `true` then `last_block_number` SHOULD NOT be
41 | * set and SHALL be ignored.
42 | * A block node implementation MAY reject any request with that does _not_
43 | * set this field `true`, but MUST clearly document that behavior.
44 | */
45 | bool retrieve_latest = 2;
46 | }
47 |
48 | /**
49 | * A response to a request for a state snapshot.
50 | *
51 | * This message SHALL deliver a _reference_ to the requested snapshot
52 | * data if successful.
53 | * This message SHALL deliver a code indicating the reason for failure
54 | * if unsuccessful.
55 | */
56 | message StateSnapshotResponse {
57 | /**
58 | * An enumeration indicating the status of a StateSnapshotResponse request.
59 | */
60 | enum Code {
61 | /**
62 | * An "unset value" flag, this value SHALL NOT be used.
63 | * This status indicates the server software failed to set a status,
64 | * and SHALL be considered a software defect.
65 | */
66 | UNKNOWN = 0;
67 |
68 | /**
69 | * The request succeeded.
70 | * The full snapshot data MAY be read via the endpoint provided in the
71 | * `snapshot_reference` field for the duration specified.
72 | */
73 | SUCCESS = 1;
74 | }
75 |
76 | /**
77 | * A status response.
78 | *
79 | * This code SHALL indicate a successful call, or the detailed
80 | * reason for failure.
81 | */
82 | Code status = 1;
83 |
84 | /**
85 | * A block number.
86 | *
87 | * This SHALL be the number of the last block included in this
88 | * state snapshot.
89 | */
90 | uint64 last_block_number = 2;
91 |
92 | /**
93 | * A reference to where the requested state snapshot may be obtained.
94 | *
95 | *
REVIEW NOTE
96 | * This is TEMPORARY. We have not yet designed how state snapshots may
97 | * be sent. One idea is to use `Any` and let implementations decide;
98 | * another is to use a time limited URL (with the same login as the block
99 | * node server); another is to use a customer-pays cloud storage bucket.
100 | *
101 | */
102 | string snapshot_reference = 3;
103 | }
104 |
105 | /**
106 | * Remote procedure calls (RPCs) for the Block Node state snapshot
107 | * and query services.
108 | */
109 | service StateService {
110 | /**
111 | * Read a state snapshot from the block node.
112 | *
113 | * The request SHALL describe the last block number present in the
114 | * snapshot.
115 | * Block node implementations MAY decline a request for a snapshot older
116 | * than the latest available, but MUST clearly document this behavior.
117 | */
118 | rpc stateSnapshot(StateSnapshotRequest) returns (StateSnapshotResponse);
119 | }
120 |
--------------------------------------------------------------------------------
/HIP/hip-323.md:
--------------------------------------------------------------------------------
1 | ---
2 | hip: 323
3 | title: C SDK
4 | author: Greg Scullard , Romain Menetrier
5 | working-group: Greg Scullard , Romain Menetrier
6 | type: Standards Track
7 | category: Application
8 | needs-council-approval: No
9 | status: Active
10 | last-call-date-time: 2022-02-01T07:00:00Z
11 | created: 2021-12-09
12 | discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/discussions/325
13 | ---
14 |
15 | ## Abstract
16 |
17 | This HIP concerns the creation of a C SDK which is currently missing from the family of Hedera SDKs. There is a .NET SDK that supports C#. However, in IoT, a native C implementation is often a requirement.
18 |
19 | ## Motivation
20 |
21 | As IoT projects take hold, particularly in the field of sustainability, an SDK that is easy to use in IoT development environments is highly desirable. A C SDK would also be preferred by many gaming solutions.
22 |
23 | ## Rationale
24 |
25 | While the initial impetus behind a C SDK was born from an IoT mindset, the SDK should be usable in all contexts and not limited to a particular desktop or IoT chipset.
26 |
27 | A .NET SDK exists, which enables development in C#, however in the context of IoT or non-Microsoft platforms, this requires the use of abstraction layers which may not always be fully compatible with the target platform and may result in heavier/more complex binaries.
28 |
29 | ## User stories
30 |
31 | As a C developer, I want to use the SDK to build solutions natively in C that can interact with Hedera.
32 |
33 | As an IoT developer, I want to be able to deploy code to my IoT platform regardless of my choice of architecture (ARM, ESP...) so that my device can interact with Hedera.
34 |
35 | As a game developer, I want to be able to build a game natively in C such that it can interact with Hedera.
36 |
37 | As a C developer, I want to be able to leverage all of Hedera's Services (Crypto, Consensus, Files, Tokens, Smart Contracts).
38 |
39 | ## Specification
40 |
41 | * The C SDK must be open source under the Apache 2.0 license
42 | * The C SDK must follow existing SDK conventions to ease developer adoption and documentation
43 | * The C SDK must have feature-parity with other SDKs and include HIPs that are under development or to be approved
44 | * The C SDK must include examples for developers to get started with minimal effort
45 | * The C SDK must be cross-platform, meaning compilation can be targeted towards IOT devices (any architecture) as well as desktop environments
46 | * The C SDK must enable signing for transactions using private keys, including key lists and threshold keys
47 | * The C SDK must support external signing through a custom implementation such as a Hardware Signing Module, which is not embedded in the SDK itself. The SDK should present the equivalent of an interface/specification for the custom implementation to adhere to
48 | * The C SDK must support a list of nodes to submit transactions to at random
49 | * The C SDK must implement an appropriate retry mechanism in the event a node is temporarily unavailable
50 | * The C SDK must implement the generation of new private keys, as well as the recovery of existing keys from mnemonics or a string representation of the key
51 | * The C SDK must implement getting Receipts and Records (and the associated error handling and retry/timeout)
52 | * The C SDK must support the Crypto Service (Create Account, Transfer, etc...)
53 | * The C SDK must support the Consensus Service (Create Topic, Submit message, etc...)
54 | * The C SDK must support the File Service (Create File, Append to File, Get File Contents, etc...)
55 | * The C SDK must support the Token Service (Create fungible token, Create non-fungible token, Mint token, Transfer token, etc...)
56 | * The C SDK must support the Smart Contract Service (Create Contract, Call Contract, Local Call, etc...)
57 | * The C SDK must support mirror subscriptions for HCS topic messages
58 |
59 | ## Backwards Compatibility
60 |
61 | None at this stage.
62 |
63 | ## Security Implications
64 |
65 | None at this stage.
66 |
67 | ## How to Teach This
68 |
69 | The SDK will include code examples for developers new to the SDK to quickly familiarise themselves with it, for example:
70 |
71 | * Creating an account
72 | * Making a HBAR transfer
73 | * Getting a receipt for a transaction
74 |
75 | ## Reference Implementation
76 |
77 | None at this stage.
78 |
79 | ## Rejected Ideas
80 |
81 | None.
82 |
83 | ## Open Issues
84 |
85 | None.
86 |
87 | ## References
88 |
89 | [Java SDK as inspiration for the C SDK](https://github.com/hashgraph/hedera-sdk-java)
90 |
91 | ## Copyright/license
92 |
93 | This document is licensed under the Apache License, Version 2.0 -- see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0)
94 |
--------------------------------------------------------------------------------
/assets/hip-1081/protobuf/block_access_service.proto:
--------------------------------------------------------------------------------
1 | // SPDX-License-Identifier: Apache-2.0
2 | syntax = "proto3";
3 |
4 | package org.hiero.block.api;
5 |
6 | option java_package = "org.hiero.block.api.protoc";
7 | // <<>> This comment is special code for setting PBJ Compiler java package
8 | option java_multiple_files = true;
9 |
10 | import "block/stream/block.proto";
11 |
12 | /**
13 | * A request to read a single block.
14 | *
15 | * A client system SHALL send this message to request a single block,
16 | * including the block state proof.
17 | */
18 | message BlockRequest {
19 | oneof block_specifier {
20 | /**
21 | * The block number of a block to retrieve.
22 | *
23 | * The requested block MUST exist on the block node.
24 | * A request MAY specify `uint64_max` to signal that the last possible
25 | * block should be returned (which is subtly different from setting
26 | * `retrieve_latest` instead of setting a `block_number`, though the
27 | * result will always be the same, in most implementations).
28 | */
29 | uint64 block_number = 1;
30 |
31 | /**
32 | * A flag to request the latest available block.
33 | *
34 | * This value SHOULD be set `true`, instead of setting `block_number`
35 | * if the intent is to request the latest block available.
36 | */
37 | bool retrieve_latest = 2;
38 | }
39 | }
40 |
41 | /**
42 | * A response to a `singleBlock` request.
43 | *
44 | * This message SHALL be sent in response to a request, and SHALL contain at
45 | * least a valid `status`.
46 | * If `status` is `READ_BLOCK_SUCCESS`, the response SHALL contain the
47 | * requested block in the `block` field.
48 | *
49 | * > Note
50 | * >> A block can become quite large. A client MUST be prepared to receive the
51 | * >> full content of the block, perhaps many megabytes of data.
52 | */
53 | message BlockResponse {
54 | /**
55 | * An enumeration indicating the status of this request.
56 | */
57 | enum Code {
58 | /**
59 | * An "unset value" flag, this value SHALL NOT be used.
60 | * This status indicates the server software failed to set a status,
61 | * and SHALL be considered a software defect.
62 | */
63 | UNKNOWN = 0;
64 |
65 | /**
66 | * The request succeeded.
67 | * The requested block SHALL be returned in the `block` field.
68 | */
69 | SUCCESS = 1;
70 |
71 | /**
72 | * The request cannot be fulfilled.
73 | * The client sent a malformed or structurally incorrect request.
74 | *
75 | * The client MAY retry the request after correcting the form and
76 | * structure.
77 | */
78 | INVALID_REQUEST = 2;
79 |
80 | /**
81 | * The requested block was not found.
82 | * Something failed and a block that SHOULD be available was
83 | * not found.
84 | * The client MAY retry the request; if this result is repeated the
85 | * request SHOULD be directed to a different block node server.
86 | */
87 | NOT_FOUND = 3;
88 |
89 | /**
90 | * The requested block is not available on this block node server.
91 | * The client SHOULD send a `serverStatus` request to determine the
92 | * lowest and highest block numbers available at this block node server.
93 | */
94 | NOT_AVAILABLE = 4;
95 | }
96 |
97 | /**
98 | * A response status.
99 | *
100 | * The reported status SHALL reflect the success of the request, or
101 | * a detailed reason the request failed.
102 | */
103 | Code status = 1;
104 |
105 | /**
106 | * The requested block.
107 | *
108 | * This container object SHALL hold the entire sequence of block items
109 | * for the requested block.
110 | * The block items in this message SHALL be in the same order
111 | * as received.
112 | * The items in this message SHALL begin with a `BlockHeader` and end with
113 | * a `BlockStateProof` applicable to this block.
114 | */
115 | com.hedera.hapi.block.stream.Block block = 2;
116 | }
117 |
118 | /**
119 | * Remote procedure calls (RPCs) for the Block Node block services.
120 | */
121 | service BlockAccessService {
122 | /**
123 | * Read a single block from the block node.
124 | *
125 | * The request SHALL describe the block number of the block to retrieve.
126 | */
127 | rpc getBlock(BlockRequest) returns (BlockResponse);
128 | }
129 |
--------------------------------------------------------------------------------
/HIP/hip-945.md:
--------------------------------------------------------------------------------
1 | ---
2 | hip: 945
3 | title: Improvements to Hedera DID Method
4 | author: Keith Kowal
5 | working-group: Keith Kowal , Derek Munneke
6 | requested-by: keith.kowal@swirldslabs.com
7 | type: Standards Track
8 | category: Application
9 | needs-council-approval: No
10 | status: Active
11 | last-call-date-time: 2024-05-06T07:00:00Z
12 | created: 2024-04-01
13 | discussions-to: https://github.com/hashgraph/did-method/pull/4
14 | requires: 27
15 | updated: 2024-05-08
16 | ---
17 |
18 | ## Abstract
19 |
20 | This HIP describes additional features building on [HIP-27](https://hips.hedera.com/hip/hip-27)
21 | The main feature addition allows DID documents to be anchored on IPFS and enables the lookup of a DID document from IPFS via a CID reference in the DID Document HCS message(s).
22 |
23 | ## Motivation
24 |
25 | Additional functionality to improve the utility of the DID:Hedera method for the community.
26 |
27 | ## Rationale
28 |
29 | The primary added feature is the ability of the DID:Hedera method to create a DID referencing a DID document that is anchored on IPFS via a CID reference. The method also then enables the lookup of a DID document from IPFS from the CID reference.
30 |
31 | The addition of this capability to HIP-27 supports alignment with the [Guardian](https://hedera.com/guardian) approach to creating DIDs.
32 |
33 | ## User stories
34 |
35 | As a user I want to create a DID:Hedera identity where the DID document is anchored on IPFS.
36 |
37 | As an identity verifier I want to lookup with the DID document that is anchored on IPFS for verification of a received identity object.
38 |
39 | ## Specification
40 |
41 | The following additions were made to the updated DID:Hedera method.
42 |
43 | ### DID Document
44 |
45 | A Hedera DID MAY be created by creating a reference to a DID document available in [IPFS](https://ipfs.io/).
46 |
47 | `DIDDocument` event value must have a JSON structure defined by a [DIDDocument-schema](DIDDocument.schema.json) and contains the following properties:
48 |
49 | - `DIDDocument` - The DIDOwner event with the following attributes:
50 | - `id` - The DID id
51 | - `type` - The document type, MAY include the DID document serialisation representation.
52 | - `cid` - The Content Identifiers to point to DID document in IPFS.
53 | - `url` - A URL to the IPFS document MAY be included for convenience.
54 |
55 | ```json
56 | {
57 | "DIDDocument": {
58 | "id": "did:hedera:testnet:z6MknSnvSESWvijDEysG1wHGnaiZSLSkQEXMECWvXWnd1uaJ_0.0.1723780",
59 | "type": "DIDDocument",
60 | "cid": "bafybeifn6wwfs355md56nhwaklgr2uvuoknnjobh2d2suzsdv6zpoxajfa/did-document.json",
61 | "url": "https://ipfs.io/ipfs/bafybeifn6wwfs355md56nhwaklgr2uvuoknnjobh2d2suzsdv6zpoxajfa/did-document.json"
62 | }
63 | }
64 | ```
65 | ## Updates to CRUD Operations
66 |
67 | ### Read
68 | Read, or Resolve, occurs by reading messages from the HCS topic set in the `did-topic-id` element of the DID namestring, and processing messages as below:
69 |
70 | 1. If the most recent valid message has `operation` set to `delete`, the DID document returned MUST be empty.
71 | **2. If the most recent valid message has `operation` set to `create`, and event object is `DIDDocument`, the DID document returned is the document resolve from the IPFS CID reference.**
72 | 3. Otherwise
73 | 1. Read valid message until one has `operation` set to `create`, and event object is `DIDOwner`.
74 | 2. Construct DID document by applying message `update` and `revoke` operations in order.
75 | 3. Return constructed DID document.
76 |
77 | ## Backwards Compatibility
78 |
79 | These changes are part of the updates to the DID:Hedera method and not backwards compatible with previous DID:Hedera method versions.
80 |
81 | ## Security Implications
82 |
83 | Individual implementers of the DID:Hedera method can decide if they wish to anchor DID documents on IPFS vs messages on Hedera Consensus Service. As part of this evaluation users should have a comprehensive understanding of IPFS, its security weaknesses, and the fact that documents on IPFS are not permanant.
84 |
85 | ## How to Teach This
86 |
87 | Documentation for updated DID Method.
88 |
89 | ## Reference Implementation
90 |
91 | The implementation for this functionality can be found in the updated DID:Hedera method
92 |
93 | ## References
94 |
95 | [DID:Hedera method](https://github.com/hashgraph/did-method/blob/master/did-method-specification.md)
96 |
97 | [HIP 27](https://hips.hedera.com/hip/hip-27)
98 |
99 | ## Copyright/license
100 |
101 | This document is licensed under the Apache License, Version 2.0 -- see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0)
102 |
--------------------------------------------------------------------------------
/HIP/hip-584.md:
--------------------------------------------------------------------------------
1 | ---
2 | hip: 584
3 | title: Mirror EVM Archive Node
4 | author: Ivan Kavaldzhiev , Mustafa Uzun
5 | requested-by: Limechain
6 | type: Standards Track
7 | category: Mirror
8 | needs-council-approval: Yes
9 | status: Final
10 | release: v0.79.0
11 | last-call-date-time: 2022-11-29T07:00:00Z
12 | created: 2022-09-27
13 | discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/discussions/586
14 | updated: 2023-02-01
15 | ---
16 |
17 | ## Abstract
18 |
19 | This HIP describes EVM execution APIs on the mirror node and transaction simulations.
20 | The HIP also describes initial Mirror Node APIs that will handle contract execution related queries,
21 | thus allowing the Mirror Node to serve the role of an EVM Archive Node.
22 |
23 | ## Motivation
24 |
25 | Ongoing user experience work needs EVM execution to enable features such as cost-free execution of
26 | read-only smart contract queries, gas estimation, and transient simulation of read-write operations.
27 |
28 | ## Rationale
29 |
30 | In order to be possible to simulate transactions Mirror Node will use a module encapsulating
31 | all of the EVM logic.
32 |
33 | The library would allow us to fulfil the following use cases:
34 |
35 | - Execute simulations that perform read-only operations
36 | - Execute transaction simulations that perform speculative writes without committing changes to state
37 | - Execute transaction simulations that perform speculative writes using historical data for transaction replay,
38 | without committing changes to state
39 |
40 | ## User stories
41 |
42 | - As a user, I want to perform `eth_call` calls from the Ethereum JSON-RPC standard
43 | - As a user, I want to perform `eth_estimateGas` calls from the Ethereum JSON-RPC standard
44 | - As a user, I want to use a library that can be used to re-run historical EVM transactions accurately so that I can inspect
45 | and debug the execution of the bytecode logic.
46 |
47 | ## Specification
48 |
49 | ### Mirror Node
50 |
51 | Information will be made available via new REST API
52 |
53 | #### Read-only queries and gas estimate REST API
54 |
55 | A new `/api/v1/contracts/call` POST REST API will be added to execute read-only queries and gas estimate.
56 | The `estimate`(if omitted = false) field in the request body would determine what the result represents.
57 |
58 | The following JSON represents a typical request body:
59 | ```json
60 | {
61 | "block": "latest",
62 | "data": "0x81a73ad500000000000000000000000000000000000000000000000000000000000004e5",
63 | "estimate": true,
64 | "from": "0x00000000000000000000000000000000000004e2",
65 | "gas": 100000000,
66 | "gas_price": 100000000,
67 | "to": "0x00000000000000000000000000000000000004e4",
68 | "value": 0
69 | }
70 | ```
71 | The following JSON represents a typical response result with the information read in the query:
72 | With the `estimate` field set to `true` in the request body:
73 | ```json
74 | {
75 | "result": "0x3234333230"
76 | }
77 | ```
78 | With the `estimate` field omitted or set to `false` in the request body:
79 | ```json
80 | {
81 | "result": "0x000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000037474740000000000000000000000000000000000000000000000000000000000"
82 | }
83 | ```
84 |
85 | ## Backwards Compatibility
86 |
87 | `Mirror Nodes` that will support the new REST APIs should have enabled importing of `CONTRACT_BYTECODE` and `CONTRACT_STATE_CHANGE`
88 | sidecar types. Otherwise, executing the endpoints would result in missing runtime bytecode for execution
89 | or using stale contract storage data.
90 |
91 | ## Security Implications
92 |
93 | There would be some security implementations for `Mirror Nodes`. Since the invocation of `eth_call` and `eth_gasEstimate` RPC calls
94 | would be free of charge and the `Mirror Nodes` don’t have throttle mechanism, some attack vectors would be possible.
95 | The Nodes could be overloaded with huge amount of calls or calls invoking smart contract methods with huge gas usage,
96 | both of which might take more system usage and slow down the network for other users. A rate limit mechanism will be implemented,
97 | so that the load put on `Mirror Nodes` to be balanced.
98 |
99 | ## How to Teach This
100 |
101 | Respective documentation will be added.
102 |
103 | ## Reference Implementation
104 |
105 | ## Rejected Ideas
106 |
107 | None.
108 |
109 | ## Open Issues
110 |
111 | None.
112 |
113 | ## References
114 |
115 | ## Copyright/License
116 |
117 | This document is licensed under the Apache License, Version 2.0 --
118 | see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0)
119 |
--------------------------------------------------------------------------------
/assets/hip-1056/protobuf/stream/output/schedule_service.proto:
--------------------------------------------------------------------------------
1 | /**
2 | * # Schedule Service
3 | * Block stream messages that report the results of transactions handled by
4 | * the `Schedule` service.
5 | *
6 | * The Schedule service handles delayed execution in two major forms.
7 | * - Transactions that only execute after being signed, via scheduleSign
8 | * transactions, with additional keys beyond the keys that signe the
9 | * scheduleCreate transaction.
10 | * - Transactions that only execute after a specified consensus time.
11 | *
12 | * Some outputs contain a scheduled transaction identifier.
13 | * That value SHALL be set if, and only if, the transaction resulted in
14 | * _execution_ of the scheduled child transaction.
15 | * Most outputs from this service SHALL NOT set the scheduled transaction
16 | * identifier, because the transaction has not executed yet. Only when the
17 | * schedule has gathered all of the signatures required to execute the
18 | * scheduled child transaction is the network able to execute that child
19 | * transaction, and assign a final transaction identifier.
20 | *
21 | * When a scheduled child transaction is executed, the identifier of the
22 | * schedule that executed that transaction SHALL be included as a
23 | * `schedule_ref` in the _result_ for the _child_ transaction.
24 | * The output of the schedule transaction (create or sign) SHALL NOT contain
25 | * the `schedule_ref`.
26 | *
27 | * ### Keywords
28 | * The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
29 | * "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
30 | * document are to be interpreted as described in
31 | * [RFC2119](https://www.ietf.org/rfc/rfc2119) and clarified in
32 | * [RFC8174](https://www.ietf.org/rfc/rfc8174).
33 | */
34 | syntax = "proto3";
35 |
36 | package com.hedera.hapi.block.stream.output;
37 |
38 | // SPDX-License-Identifier: Apache-2.0
39 |
40 | option java_package = "com.hedera.hapi.block.stream.output.protoc";
41 | // <<>> This comment is special code for setting PBJ Compiler java package
42 | option java_multiple_files = true;
43 |
44 | import "basic_types.proto";
45 |
46 | /**
47 | * Block Stream data for a `createSchedule` transaction.
48 | *
49 | * This message SHALL NOT duplicate information already contained in
50 | * the original transaction.
51 | */
52 | message CreateScheduleOutput {
53 | /**
54 | * A schedule identifier.
55 | *
56 | * If the status of the transaction is `SUCCESS`, this value SHALL be
57 | * set to the identifier of the schedule that was created. If the
58 | * transaction status is `IDENTICAL_SCHEDULE_ALREADY_CREATED`, this
59 | * value SHALL be set to the identifier of the existing schedule that
60 | * is identical to the one that was attempted to be created. For any
61 | * other status, this value SHALL NOT be set.
62 | */
63 | proto.ScheduleID schedule_id = 1;
64 |
65 | /**
66 | * A scheduled transaction identifier.
67 | *
68 | * This value SHALL be the transaction identifier for the _scheduled_
69 | * child transaction executed as a result of gathering sufficient
70 | * signatures to complete the schedule.
71 | * This value SHALL NOT be set unless the scheduled transaction was
72 | * executed as a child of this schedule create transaction.
73 | * This value SHALL NOT be set unless this schedule create transaction
74 | * was signed by sufficient keys to meet the signature requirements
75 | * for the scheduled child transaction immediately.
76 | */
77 | proto.TransactionID scheduled_transaction_id = 2;
78 | }
79 |
80 | /**
81 | * Block Stream data for a `deleteSchedule` transaction.
82 | *
83 | * This message SHALL NOT duplicate information already contained in
84 | * the original transaction.
85 | */
86 | message DeleteScheduleOutput {}
87 |
88 | /**
89 | * Block Stream data for a `signSchedule` transaction.
90 | *
91 | * This message SHALL NOT duplicate information already contained in
92 | * the original transaction.
93 | */
94 | message SignScheduleOutput {
95 | /**
96 | * A scheduled transaction identifier.
97 | *
98 | * This value SHALL be the transaction identifier for the _scheduled_
99 | * child transaction executed as a result of gathering sufficient
100 | * signatures to complete the schedule.
101 | * This value SHALL NOT be set unless the scheduled transaction was
102 | * executed as a child of this schedule sign transaction.
103 | * This value SHALL NOT be set unless this schedule sign transaction
104 | * was signed by sufficient additional keys to meet the signature
105 | * requirements for the scheduled child transaction.
106 | */
107 | proto.TransactionID scheduled_transaction_id = 1;
108 | }
109 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | 
2 |
3 | [](https://discord.com/channels/905194001349627914/1289954446712770600)
4 | [](https://hips.hedera.org)
5 | [](https://scorecard.dev/viewer/?uri=github.com/hiero-ledger/hiero-improvement-proposals)
6 | [](https://bestpractices.coreinfrastructure.org/projects/10697)
7 | [](LICENSE)
8 |
9 | ## Submit a HIP
10 | 1. Fork this repository
11 | 1. Fill out this template: [hip template](hip-0000-template.md)
12 | 1. If the proposal contains exceptionally large specification text,
13 | particularly API changes or source code, place those changes
14 | in `assets` and link them as described in the template document.
15 | 1. Create a pull request against hiero-ledger/hiero-improvement-proposals main
16 |
20 |
21 | See [hip-1](HIP/hip-1.md) for details on the HIP process.
22 |
23 | ## What is a HIP?
24 | HIP stands for "Hiero Improvement Proposal". These improvement proposals can
25 | range from core protocol changes, to the applications, frameworks, and protocols
26 | built on top of the Hiero network and used by the community. The HIP
27 | author is responsible for building consensus within the community and
28 | documenting dissenting opinions, as well as tracking their HIP through
29 | the process outlined below.
30 |
31 | You can see the list of all HIPs on [the official HIPs site](https://hips.hiero.org).
32 |
33 | ## What is Hiero?
34 | [Hiero](https://hiero.org) is an open-source distributed ledger project under
35 | the Linux Foundation Decentralized Trust (LF Decentralized Trust). Hiero builds
36 | upon the [Hashgraph consensus algorithm](http://www.leemon.com/papers/2016b.pdf)
37 | created by [Dr. Leemon Baird](http://www.leemon.com/). The project provides a
38 | fast, fair, and secure environment for distributed ledger technologies. You can
39 | learn more about the Hashgraph Consensus Algorithm by reading the
40 | [hashgraph algorithm whitepaper](http://www.leemon.com/papers/2016b.pdf).
41 |
42 | ## Purpose
43 | The goal of HIPs is to have a place to propose new features, to collect
44 | community thoughts and input on a particular issue, and further to document
45 | all these subject matters in one place. It's a great way to document these
46 | discussions and proposals
47 | [here on GitHub](https://github.com/hiero-ledger/hiero-improvement-proposals),
48 | because any revisions made on these text files will be recorded.
49 |
50 | ## Qualifications
51 | Each HIP should only be one single key proposal and/or idea. The idea should be
52 | focused and only issue to one subject matter to be successful. A HIP must meet
53 | certain minimum criteria: it must be clear and have a complete description of
54 | the proposed enhancement, the enhancement must represent a net improvement,
55 | the proposed implementation, if applicable, must be solid and must not
56 | complicate the protocol unduly.
57 |
58 | ## Before Submitting
59 | 1. Evaluate your idea: consider why you'd like to request changes or
60 | improvements, and how it benefits the Hiero community.
61 | 1. Thoroughly look through those proposals already submitted to ensure there
62 | are no duplicates.
63 | 1. Ask the Hiero community first if your idea is original, or has
64 | already been through the HIP process.
65 | 1. Reevaluate your proposal to ensure sure the idea is applicable
66 | to the entire community and not just to one particular author, application,
67 | project, or protocol.
68 |
69 | ## Local Jekyll Site
70 | Pre-requisites:
71 | - `ruby`: `2.7.8p225`
72 | - `gem`: `3.4.10`
73 | - `bundler`: `1.17.3`
74 | You can run a local version of the HIPs dashboard site:
75 | ```shell
76 | bundle install
77 | bundle exec jekyll serve --livereload
78 | ```
79 | The site will be available on `http://localhost:4000`.
80 |
81 | You can read more about Jekyll on its official [website](https://jekyllrb.com/)
82 |
83 | ##### Note
84 | An excellent place to discuss your proposal and get feedback is in the
85 | [issues section of this repository](https://github.com/hiero-ledger/hiero-improvement-proposals/issues),
86 | or on [LFDT's Discord Server](https://discord.com/channels/905194001349627914/1289954446712770600);
87 | there you can start formalizing the language around your HIP and ensuring it has broad
88 | community support.
89 |
90 | ## Disclaimer(s):
91 | These proposals and discussions have no effect regarding private (permissioned)
92 | implementations of the Hashgraph consensus algorithm; additionally, this
93 | repository and its contents are maintained by the Hiero community under the
94 | governance of the Linux Foundation Decentralized Trust.
95 |
--------------------------------------------------------------------------------
/HIP/hip-227.md:
--------------------------------------------------------------------------------
1 | ---
2 | hip: 227
3 | title: Mirror Node Search Contract Execution Log REST API
4 | author: Nana Essilfie-Conduah (@Nana-EC)
5 | type: Standards Track
6 | category: Mirror
7 | needs-council-approval: Yes
8 | discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/discussions/264
9 | status: Final
10 | last-call-date-time: 2021-12-20T07:00:00Z
11 | release: v0.47.0
12 | created: 2021-11-18
13 | updated: 2023-02-01
14 | ---
15 |
16 | ## Abstract
17 |
18 | An additional Mirror Node REST API endpoint is described which would allow users to search across topics for a particular contracts execution results.
19 |
20 | ## Motivation
21 |
22 | The current Mirror Node supports the ingestion of contract information and contract executions results and logs.
23 | It supports the retrieval of top level contract information, however, it does not support the filtering of contract execution result logs.
24 | When methods in a contract are run users currently have to rely on network calls and transaction success or failure to determine execution details.
25 | Retrieving filtered transaction logs is common practice in the EVM space and the Mirror Node should provide endpoints on its existing API to support new and existing users.
26 |
27 | ## Rationale
28 |
29 | The proposal seeks to expand Mirror Node Smart Contract Service 2.0 support by exposing contract execution result logs filtering as is standard in many full archive nodes.
30 | This new endpoint would provide insight into function execution logs.
31 |
32 | ## User stories
33 |
34 | As a user, I want to filter through and view the results of a smart contracts method execution
35 |
36 | ## Specification
37 |
38 | A new endpoint `/api/v1/contracts/{id}/results/logs` will be added to supports users filtering contract execution result logs.
39 |
40 | The following JSON represents a typical response result from either of these calls
41 | ```json
42 | {
43 | "logs": [
44 | {
45 | "address": "0x0000000000000000000000000000000000001234",
46 | "bloom": "0x1513001083c899b1996ec7fa33621e2c340203f0",
47 | "contract_id": "0.0.1002",
48 | "data": "0x8f705727c88764031b98fc32c314f8f9e463fb62",
49 | "index": 0,
50 | "root_contract_id": null,
51 | "timestamp": "12345.10002",
52 | "topics": [
53 | "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
54 | "0x59d088293f09d5119d5b55858b989ffce4d398dc"
55 | ]
56 | },
57 | {
58 | "address": "0x0000000000000000000000000000000000001893",
59 | "bloom": "0x8f705727c88764031b98fc32c314f8f9e463fb62",
60 | "contract_id": "0.0.1003",
61 | "data": "0x1513001083c899b1996ec7fa33621e2c340203f0",
62 | "index": 1,
63 | "root_contract_id": "0.0.1002",
64 | "timestamp": "12345.10002",
65 | "topics": [
66 | "af846d22986843e3d25981b94ce181adc556b334ccfdd8225762d7f709841df0",
67 | "0000000000000000000000000000000000000000000000000000000000000765"
68 | ]
69 | }
70 | ]
71 | }
72 | ```
73 |
74 | Optional filters
75 |
76 | - `index`: The unique log index within a particular contract result. Starts at zero and increases.
77 | - `limit`: The maximimum number of items to return in response.
78 | - `order`: The order in which items are listed - asc or desc (default). Sort fields are `timestamp` then `index`.
79 | - `timestamp`: The consensus timestamp in `seconds.nanoseconds` format. Required when a topic is specified and should not span a time range of more than seven days. Supports optional comparison operators `gt`, `gte`, `lt`, `lte`, or `eq`.
80 | - `topic0`: The first topic associated with a contract log. Topic should be hex encoded with `0x` characters optional.
81 | - `topic1`: The second topic associated with a contract log. Topic should be hex encoded with `0x` characters optional.
82 | - `topic2`: The third topic associated with a contract log. Topic should be hex encoded with `0x` characters optional.
83 | - `topic3`: The fourth topic associated with a contract log. Topic should be hex encoded with `0x` characters optional.
84 |
85 | > **_NOTE:_** Paging will not be supported if number of logs exceed the page size (default 25), optional parameters will need to be adjusted by callers in this case.
86 |
87 | ## Backwards Compatibility
88 |
89 | This additional API endpoint does not alter exsiting REST API functionality.
90 |
91 | ## How to Teach This
92 |
93 | - Hedera Mirror Node design document
94 | - Description and code examples of queries added to Hedera REST API documentation section
95 | - The OpenAPI spec at `api/v1/docs` should be updated to reflect the new endpoints and allow users to test out the calls.
96 | - Reviewed in Engineering Insights
97 |
98 |
99 | ## References
100 |
101 | - https://github.com/hashgraph/hedera-protobufs/blob/main/services/contract_call_local.proto
102 |
103 | ## Copyright/license
104 |
105 | This document is licensed under the Apache License, Version 2.0 -- see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0)
106 |
--------------------------------------------------------------------------------
/HIP/hip-844.md:
--------------------------------------------------------------------------------
1 | ---
2 | hip: 844
3 | title: Handling and externalisation improvements for account nonce updates
4 | author: Stoyan Panayotov
5 | working-group: Nana Essilfie-Conduah , Danno Ferrin , Steven Sheehy
6 | type: Standards Track
7 | needs-council-approval: Yes
8 | category: Service
9 | status: Final
10 | release: v0.47.0
11 | last-call-date-time: 2024-02-08T07:00:00Z
12 | created: 2023-12-12
13 | discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/discussions/845
14 | updated: 2024-05-08
15 | ---
16 |
17 | ## Abstract
18 |
19 | Introduce rules for when to update an Ethereum transaction signer's nonce and a new field for externalising the nonce update in the record stream. This will help resolve issues where the Consensus nodes and the Mirror nodes are out of sync in regards to what the current value of an account's nonce is.
20 |
21 | ## Motivation
22 |
23 | Unclear rules for when the nonce of an EthereumTransaction signer account should be updated result in discrepancies between the Consensus nodes' and Mirror nodes' states. This leads to users experiencing issues when reading the account nonce from the Mirror node and trying to use it in a transaction sent to the Consensus node.
24 |
25 | ## Rationale
26 |
27 | The nonce of a signer of an Ethereum transaction should be increased for all transactions that are executed in the EVM.
28 |
29 | Transactions that have reached consensus and are handled by the node but have failed additional validations performed by the node prior to being executed in the EVM should have no effect on the Ethereum transaction signer nonce.
30 |
31 | A new protobuf field in the record stream - signerNonce - should be populated by the node with the current value of the signer account nonce after executing the transaction. This value should be used by the Mirror nodes when importing record stream files.
32 |
33 | ## User stories
34 |
35 | 1. As a Mirror node operator, I would like to receive information about incremented account nonces from the record stream produced by the consensus nodes.
36 | 2. As a web3 user of the network, I would like to be able to more easily submit transactions without having to change the transaction nonce manualy.
37 |
38 | ## Specification
39 |
40 | ### Protobuf update
41 |
42 | Add a new protobuf field to contract_call_local.proto:
43 |
44 | ```
45 | message ContractFunctionResult {
46 |
47 | [...]
48 |
49 | /**
50 | * If not null this field specifies what the value of the signer account nonce is post transaction execution.
51 | * For transactions that don't update the signer nonce (like HAPI ContractCall and ContractCreate transactions) this field should be null.
52 | */
53 | Int64Value signer_nonce = 15;
54 | }
55 | ```
56 |
57 | ### Services update
58 |
59 | 1. Move the signer nonce update to be right before the node spins up the EVM and starts the transaction execution in the EVM.
60 | 2. Populate the new protobuf field when externalising the transaction.
61 | 3. Initially, populate the new protobuf field with the actual signer nonce value after the transaction execution even if the nonce on the account is unchagned. This will allow the Mirror node to update any incorrect nonce values stored without the users having to manually update the nonce on the transactions they're sending.
62 |
63 | ### Mirror node update
64 |
65 | When importing transactions from the record stream, update the value of the signer account's nonce that's persisted on the mirror node side with the value externalised in the new protobuf field.
66 |
67 | ## Backward Compatibility
68 |
69 | When importing legacy transactions that don't have this field, the Mirror node should consider whether the transaction result is SUCCESS or CONTRACT_REVERT_EXECUTED and increment the signer nonce in these cases. Some statuses such as INSUFFICIENT_GAS can be returned both before and after entering the EVM, there is no way for the Mirror node to know whether the signer nonce should be updated. This was the root cause of multiple issues and the reason for the new protobuf field.
70 |
71 | The Mirror node will continue to serve outdated nonce information for some accounts and will provide accurate nonces for accounts that have signed valid EthereumTransactions post this HIP implementation.
72 |
73 | Users that experience issues such as the following error when they attempt to sign and send Ethereum transactions through the JSON-RPC Relay: `Nonce too low. Provided nonce: 0, current nonce: 0` should be able to unblock themselves by increasing the nonce property of the transaction they're sending with 1.
74 |
75 | ## Security Implications
76 |
77 | Having consistency between Mirror node and Consensus node states will improve the overall network security and improve the user experience.
78 |
79 | ## How to Teach This
80 |
81 | Respective documentation will be added.
82 |
83 | ## References
84 |
85 | ## Open Issues
86 |
87 | ## Copyright/license
88 |
89 | This document is licensed under the Apache License, Version 2.0 -- see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0)
90 |
--------------------------------------------------------------------------------
/HIP/hip-850.md:
--------------------------------------------------------------------------------
1 | ---
2 | hip: 850
3 | title: Enhancing Supply Key Functionality for NFT Updates in Treasury Account
4 | author: Patches (@HGraphPunks)
5 | type: Standards Track
6 | category: Core
7 | needs-council-approval: Yes
8 | status: Final
9 | release: 0.53.5
10 | last-call-date-time: 2024-06-12T07:00:00Z
11 | created: 2024-01-02
12 | discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/discussions/660
13 | requested-by: HGraphPunks, TierBot
14 | updated: 2024-10-23
15 | ---
16 |
17 | ## Abstract
18 |
19 | This HIP proposes enhancing the Supply Key functionality within the Hedera ecosystem, specifically enabling the Supply Key to update an NFT metadata field while the NFT is held in the treasury account. This ensures secure and controlled adaptability of NFTs, meeting dynamic needs while maintaining their integrity post-distribution.
20 |
21 | ## Motivation
22 |
23 | Currently, there is a limitation in dynamically updating NFTs in a controlled manner. The proposed enhancement to the Supply Key functionality addresses this gap, allowing for secure and selective updates of NFTs within the treasury account, a feature particularly relevant for various evolving use cases in the Hedera ecosystem.
24 |
25 | ## Rationale
26 |
27 | The enhancement focuses on granting the Supply Key the capability to update the data of an NFT serial number exclusively while it is in the treasury account. This approach ensures security and control, preventing unauthorized modifications once the NFT is distributed.
28 |
29 | ## User Stories
30 |
31 | - As a stakeholder, I need the capability to update the metadata of NFTs within the treasury account to reflect the latest information, ensuring that once the NFTs are distributed, their data remains immutable.
32 |
33 | ### Example Illustrations:
34 | - As a game developer, I want to update game piece NFTs with player stats during gameplay, ensuring the data becomes immutable once the player regains ownership.
35 | - As an event organizer, I need to update event ticket NFTs with attendee information while they are in the treasury account, guaranteeing data immutability post-transfer.
36 |
37 | ## Specification
38 |
39 | This HIP requires an update to the Supply Key mechanism, enabling it to modify the metadata of NFTs while they are held in the treasury account. Specifically, this update introduces the capability for the Supply Key to execute the TokenUpdateNftsTransaction function, allowing for the metadata of an NFT ID to be updated while it resides in the treasury wallet. This enhancement provides a controlled method to adapt NFT metadata dynamically, ensuring that the NFT data remains immutable once distributed. This approach maintains the integrity and trust in the NFT ecosystem by preventing unauthorized modifications post-distribution.
40 |
41 | ## Backwards Compatibility
42 |
43 | This proposal introduces a change in the defined capabilities of the Supply Key, which could affect the expectations of users regarding the immutability of NFT metadata. Although the Supply Key can currently burn and mint new tokens, allowing it to update metadata without burning introduces a conceptual difference. Users must be aware that the metadata of an NFT can be altered while it is in the treasury account, which can impact the perceived consistency and promises of an NFT collection.
44 |
45 | ## Security Implications
46 |
47 | The primary security consideration is the prevention of unauthorized data modifications to NFTs post-distribution. The treasury account requirement for updates addresses this concern effectively.
48 |
49 | There is no added security concern with the ability of Supply Key to adapt the metadata when in the treasury account as the Supply Key can also burn and mint new tokens. The security implications of sending a NFT to a treasury account that has a Supply Key enabled do not become worse or better with this HIP.
50 |
51 | ### Modification of Previously Immutable Data
52 | This HIP introduces a change to the previous guarantee of immutability for NFT metadata. It is important to note that, under the new functionality, the metadata of an NFT can be updated while it resides in the treasury account. This modification capability, while restricted to the treasury account, is a departure from the guarantee of immutability that was previously assured for NFT metadata once minted. Stakeholders should be aware that this change allows for a controlled flexibility in specific circumstances, while still ensuring that the metadata becomes immutable once the NFT is distributed to end-users.
53 |
54 | ## How to Teach This
55 |
56 | Educational initiatives will be developed to guide users in leveraging the new Supply Key functionality, particularly focusing on use cases like gaming and event management.
57 |
58 | ## Reference Implementation
59 |
60 | The reference implementation will be comprehensive, including detailed documentation and test cases. Completion is expected prior to the HIP achieving "Final" status.
61 |
62 | ## Rejected Ideas
63 |
64 | ## Open Issues
65 |
66 |
67 | ## References
68 |
69 |
70 | ## Copyright/license
71 |
72 | This document is licensed under the Apache License, Version 2.0. See [LICENSE](https://www.apache.org/licenses/LICENSE-2.0).
73 |
74 | ---
75 |
--------------------------------------------------------------------------------
/_includes/anchor_headings.html:
--------------------------------------------------------------------------------
1 | {% capture headingsWorkspace %}
2 | {% comment %}
3 | Version 1.0.5
4 | https://github.com/allejo/jekyll-anchor-headings
5 |
6 | "Be the pull request you wish to see in the world." ~Ben Balter
7 |
8 | Usage:
9 | {% include anchor_headings.html html=content %}
10 |
11 | Parameters:
12 | * html (string) - the HTML of compiled markdown generated by kramdown in Jekyll
13 |
14 | Optional Parameters:
15 | * beforeHeading (bool) : false - Set to true if the anchor should be placed _before_ the heading's content
16 | * anchorAttrs (string) : '' - Any custom HTML attributes that will be added to the `` tag; you may NOT use `href`, `class` or `title`
17 | * anchorBody (string) : '' - The content that will be placed inside the anchor; the `%heading%` placeholder is available
18 | * anchorClass (string) : '' - The class(es) that will be used for each anchor. Separate multiple classes with a space
19 | * anchorTitle (string) : '' - The `title` attribute that will be used for anchors
20 | * h_min (int) : 1 - The minimum header level to build an anchor for; any header lower than this value will be ignored
21 | * h_max (int) : 6 - The maximum header level to build an anchor for; any header greater than this value will be ignored
22 | * bodyPrefix (string) : '' - Anything that should be inserted inside of the heading tag _before_ its anchor and content
23 | * bodySuffix (string) : '' - Anything that should be inserted inside of the heading tag _after_ its anchor and content
24 |
25 | Output:
26 | The original HTML with the addition of anchors inside of all of the h1-h6 headings.
27 | {% endcomment %}
28 |
29 | {% assign minHeader = include.h_min | default: 1 %}
30 | {% assign maxHeader = include.h_max | default: 6 %}
31 | {% assign beforeHeading = include.beforeHeading %}
32 | {% assign nodes = include.html | split: '
47 | {% if headerLevel == 0 %}
48 |
49 | {% assign firstChunk = node | split: '>' | first %}
50 |
51 |
52 | {% unless firstChunk contains '<' %}
53 | {% capture node %}' | first }}>{% endcapture %}
66 | {% assign header = _workspace[0] | replace: _hAttrToStrip, '' %}
67 |
68 |
69 | {% capture anchor %}{% endcapture %}
70 |
71 | {% if html_id and headerLevel >= minHeader and headerLevel <= maxHeader %}
72 | {% capture anchor %}href="#{{ html_id }}"{% endcapture %}
73 |
74 | {% if include.anchorClass %}
75 | {% capture anchor %}{{ anchor }} class="{{ include.anchorClass }}"{% endcapture %}
76 | {% endif %}
77 |
78 | {% if include.anchorTitle %}
79 | {% capture anchor %}{{ anchor }} title="{{ include.anchorTitle | replace: '%heading%', header }}"{% endcapture %}
80 | {% endif %}
81 |
82 | {% if include.anchorAttrs %}
83 | {% capture anchor %}{{ anchor }} {{ include.anchorAttrs }}{% endcapture %}
84 | {% endif %}
85 |
86 | {% capture anchor %}{{ include.anchorBody | replace: '%heading%', header | default: '' }}{% endcapture %}
87 |
88 |
89 | {% if beforeHeading %}
90 | {% capture anchor %}{{ anchor }} {% endcapture %}
91 | {% else %}
92 | {% capture anchor %} {{ anchor }}{% endcapture %}
93 | {% endif %}
94 | {% endif %}
95 |
96 | {% capture new_heading %}
97 |
5 | working-group: Steven Sheehy <@steven-sheehy>
6 | requested-by: Swirlds Labs
7 | type: Standards Track
8 | category: Service
9 | needs-council-approval: Yes
10 | status: Final
11 | release: v0.42.0
12 | last-call-date-time: 2023-09-12T07:00:00Z
13 | created: 2023-08-28
14 | discussions-to: https://github.com/hiero-ledger/hiero-improvement-proposals/discussions/798
15 | updated: 2023-09-13
16 | ---
17 |
18 | ## Abstract
19 |
20 | This HIP proposes sunsetting the [account balance file](https://github.com/hashgraph/hedera-protobufs/blob/main/streams/account_balance_file.proto). This stream file is generated every 15 minutes by consensus nodes and contains every active account's hbar balance as well as its token balances.
21 |
22 | ## Motivation
23 |
24 | The ongoing success of the Hedera Network has caused an enormous growth of the data stored in consensus nodes. To ensure the continuous delivery of stable and responsive services, functionality that requires reading large amounts of data has to be disabled on consensus nodes and moved to other systems.
25 |
26 | ## Rationale
27 |
28 | Calculating and providing balance files requires iterating over all accounts. This causes many disk reads, which can interfere with normal operations.
29 |
30 | ## User stories
31 |
32 | * As a user, I want a stable and responsive system that does not degrade as the usage scales out.
33 |
34 | * As a mirror node operator, I want to provide accurate balance information to users.
35 |
36 | ## Specification
37 |
38 | Producing and making the balance file available will be stopped completely.
39 |
40 | ## Backwards Compatibility
41 |
42 | Systems that depend on balance file availability must adapt and change to generate balance information from record files. It is an open discussion if balance files should be provided in the future using other techniques.
43 |
44 | ## Security Implications
45 |
46 | Mirror node operators who don't update their software to generate balance information from record files may return stale balance information to their users for a period of time. This can cause users to be concerned that their transactions do not appear to have had the expected effect on their account or token.
47 |
48 | ## How to Teach This
49 |
50 | Any references to balance files in Hedera documentation should be de-emphasized or removed. Mirror node operators should be aware of how their software uses balance files and taught how to generate similar information from the record files.
51 |
52 | ## Reference Implementation
53 |
54 | The [Hedera Mirror Node](https://github.com/hiero-ledger/hiero-mirror-node) will release version 0.88 with support for generating the balance snapshot from the record file. Mirror node operators using the open source mirror node software only need to upgrade to this version before the balance file sunset date to ensure no impact to users.
55 |
56 | For operators not using the open source software and relying upon the balance file for the current or historical balance information, the changes necessary will vary per codebase. Below is pseudo-code for keeping the current balance up to date where the domain model and repositories would be provided by the app. To generate a historical balance snapshot of this information would just require a cron process that runs every 15 minutes that duplicates the balance data from the operator's account and token relationship tables.
57 |
58 | ```java
59 | public void updateBalances(RecordStreamFile recordFile) {
60 | recordFile.getRecordStreamItemsList().forEach(recordItem -> {
61 | recordItem.getRecord().getTransferList().getAccountAmountsList().forEach(accountAmount -> {
62 | var account = accountRepository.find(accountAmount.getAccountID());
63 | account.setBalance(account.getBalance() + accountAmount.getAmount());
64 | accountRepository.save(account);
65 | });
66 |
67 | recordItem.getRecord().getTokenTransferListsList().forEach(t -> {
68 | t.getTransfersList().forEach(accountAmount -> {
69 | var tokenRelationship = tokenRelationshipRepository.find(t.getToken(), accountAmount.getAccountID());
70 | tokenRelationship.setBalance(tokenRelationship.getBalance() + accountAmount.getAmount());
71 | tokenRelationshipRepository.save(tokenRelationship);
72 | });
73 | });
74 | });
75 | }
76 | ```
77 |
78 | ## Rejected Ideas
79 |
80 | All ideas that produced the balance file on consensus nodes were rejected because they would not solve the original problem of vast numbers of file reads.
81 |
82 | ## Open Issues
83 |
84 | It is under discussion if balance files can be provided with a process that does not involve analyzing the data on consensus nodes.
85 |
86 | ## References
87 |
88 | * [Account Balance File Protobuf](https://github.com/hashgraph/hedera-protobufs/blob/main/streams/account_balance_file.proto)
89 | * [Hedera Mirror Node](https://github.com/hiero-ledger/hiero-mirror-node)
90 |
91 | ## Copyright/license
92 |
93 | This document is licensed under the Apache License, Version 2.0 -- see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0)
94 |
--------------------------------------------------------------------------------