Skip to content

Commit 3b7917b

Browse files
mgarbsmgarbs
authored
Merge branch 'main' into update_token_keys
2 parents 62e2fb0 + 00098c5 commit 3b7917b

28 files changed

+3105
-380
lines changed

‎.github/CODEOWNERS

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -8,16 +8,16 @@
88
# NOTE: Must be placed last to ensure enforcement over all other rules
99

1010
# Protection Rules for Github Configuration Files and Actions Workflows
11-
/.github/ @hashgraph/devops-ci @hashgraph/release-engineering-managers
12-
/.github/workflows/ @hashgraph/devops-ci @devops-ci-committers
11+
/.github/ @hashgraph/platform-ci @hashgraph/release-engineering-managers
12+
/.github/workflows/ @hashgraph/platform-ci
1313

1414
# Self-protection for root CODEOWNERS files (this file should not exist and should definitely require approval)
1515
/CODEOWNERS @hashgraph/release-engineering-managers
1616

1717
# Protect the repository root files
18-
/README.md @hashgraph/devops-ci @hashgraph/release-engineering-managers
18+
/README.md @hashgraph/platform-ci @hashgraph/release-engineering-managers
1919
**/LICENSE @hashgraph/release-engineering-managers
2020

2121
# Git Ignore definitions
22-
**/.gitignore @hashgraph/devops-ci @hashgraph/release-engineering-managers
23-
**/.gitignore.* @hashgraph/devops-ci @hashgraph/release-engineering-managers
22+
**/.gitignore @hashgraph/platform-ci @hashgraph/release-engineering-managers
23+
**/.gitignore.* @hashgraph/platform-ci @hashgraph/release-engineering-managers

‎.github/workflows/update-draft-hips.yml

Lines changed: 134 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,134 @@
1+
name: Update Draft HIPs Data
2+
3+
on:
4+
schedule:
5+
- cron: "0 */6 * * *" # Runs every 6 hours
6+
workflow_dispatch: # Allows manual triggering
7+
8+
jobs:
9+
update-draft-hips:
10+
if: github.ref == 'refs/heads/main' # Only run on main branch
11+
runs-on: improvement-proposals-linux-medium
12+
permissions:
13+
contents: write
14+
pull-requests: read
15+
steps:
16+
- name: Checkout Code
17+
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
18+
with:
19+
token: ${{ secrets.GH_ACCESS_TOKEN }}
20+
21+
- name: Import GPG Key
22+
id: gpg_importer
23+
uses: step-security/ghaction-import-gpg@6c8fe4d0126a59d57c21f87c9ae5dd3451fa3cca # v6.1.0
24+
with:
25+
git_commit_gpgsign: true
26+
git_tag_gpgsign: true
27+
git_user_signingkey: true
28+
gpg_private_key: ${{ secrets.GPG_KEY_CONTENTS }}
29+
passphrase: ${{ secrets.GPG_KEY_PASSPHRASE }}
30+
31+
- name: Setup Node.js
32+
uses: actions/setup-node@64ed1c7eab4cce3362f8c340dee64e5eaeef8f7c # v3.6.0
33+
with:
34+
node-version: "20"
35+
36+
- name: Create Script
37+
run: |
38+
mkdir -p _data
39+
cat << 'EOF' > fetch-draft-hips.js
40+
const https = require('https');
41+
42+
async function makeGraphQLRequest(query, token) {
43+
return new Promise((resolve, reject) => {
44+
const options = {
45+
hostname: 'api.github.com',
46+
path: '/graphql',
47+
method: 'POST',
48+
headers: {
49+
'Authorization': `Bearer ${token}`,
50+
'Content-Type': 'application/json',
51+
'User-Agent': 'Node.js'
52+
}
53+
};
54+
55+
const req = https.request(options, (res) => {
56+
let data = '';
57+
res.on('data', chunk => { data += chunk; });
58+
res.on('end', () => resolve(JSON.parse(data)));
59+
});
60+
61+
req.on('error', reject);
62+
req.write(JSON.stringify({ query }));
63+
req.end();
64+
});
65+
}
66+
67+
async function getAllPRs() {
68+
const query = `
69+
query {
70+
repository(name: "hedera-improvement-proposal", owner: "hashgraph") {
71+
pullRequests(first: 100, states: [OPEN], orderBy: {field: CREATED_AT, direction: DESC}) {
72+
nodes {
73+
title
74+
number
75+
url
76+
headRefOid
77+
files(first: 100) {
78+
edges {
79+
node {
80+
path
81+
additions
82+
deletions
83+
}
84+
}
85+
}
86+
author {
87+
login
88+
}
89+
}
90+
}
91+
}
92+
}
93+
`;
94+
95+
try {
96+
const result = await makeGraphQLRequest(query, process.env.GITHUB_TOKEN);
97+
98+
if (result.errors) {
99+
console.error('GraphQL errors:', result.errors);
100+
process.exit(1);
101+
}
102+
103+
return result.data.repository.pullRequests.nodes;
104+
} catch (error) {
105+
console.error('Error fetching PRs:', error);
106+
throw error;
107+
}
108+
}
109+
110+
// Run the main function
111+
getAllPRs().then(prs => {
112+
const fs = require('fs');
113+
fs.writeFileSync('_data/draft_hips.json', JSON.stringify(prs, null, 2));
114+
}).catch(error => {
115+
console.error('Failed to fetch PRs:', error);
116+
process.exit(1);
117+
});
118+
EOF
119+
120+
- name: Run Script
121+
run: node fetch-draft-hips.js
122+
env:
123+
GITHUB_TOKEN: ${{ secrets.GH_ACCESS_TOKEN }}
124+
125+
- name: Commit and Push Changes
126+
env:
127+
GITHUB_USER_EMAIL: ${{ secrets.GIT_USER_EMAIL }}
128+
GITHUB_USER_NAME: ${{ secrets.GIT_USER_NAME }}
129+
run: |
130+
git config --local user.email "$GITHUB_USER_EMAIL"
131+
git config --local user.name "$GITHUB_USER_NAME"
132+
git add _data/draft_hips.json
133+
git commit -s -S -m "Update draft HIPs data [skip ci]" || echo "No changes to commit"
134+
git push origin main || echo "No changes to push"

‎Gemfile.lock

Lines changed: 10 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -54,14 +54,23 @@ GEM
5454
rb-fsevent (0.11.0)
5555
rb-inotify (0.10.1)
5656
ffi (~> 1.0)
57-
rexml (3.2.5)
57+
rexml (3.2.8)
58+
strscan (>= 3.0.9)
5859
rouge (3.26.0)
5960
safe_yaml (1.0.5)
6061
sass (3.7.4)
6162
sass-listen (~> 4.0.0)
6263
sass-listen (4.0.0)
6364
rb-fsevent (~> 0.9, >= 0.9.4)
6465
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)
6574
thread_safe (0.3.6)
6675
tzinfo (1.2.10)
6776
thread_safe (~> 0.1)

‎HIP/hip-1010.md

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -6,13 +6,14 @@ working-group: Nana Essilfie-Conduah <nana@swirldslabs.com>, Luke Lee <luke.lee
66
type: Standards Track
77
category: Service
88
needs-council-approval: Yes
9-
status: Accepted
9+
status: Final
10+
release: v0.54.2
1011
last-call-date-time: 2024-08-14T07:00:00Z
1112
created: 2024-07-11
1213
discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/pull/1010
1314
requires: 18, 206, 514
1415
requested-by: IOBuilders
15-
updated: 2024-08-16
16+
updated: 2024-11-04
1617
---
1718

1819
## Abstract

‎HIP/hip-1021.md

Lines changed: 65 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,65 @@
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+
needs-tsc-approval: Yes
8+
status: Last Call
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/hashgraph/hedera-improvement-proposal/pull/1021
13+
needs-council-approval: Yes
14+
updated: 2024-01-08
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/hashgraph/hedera-improvement-proposal/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+

‎HIP/hip-1037.md

Lines changed: 117 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,117 @@
1+
---
2+
hip: 1037
3+
title: Protocol Buffer API Specification
4+
author: Joseph Sinclair <@jsync-swirlds>
5+
requested-by: Richard Bair <@rbair>
6+
type: Standards Track
7+
category: Service
8+
needs-tsc-approval: Yes
9+
status: Last Call
10+
created: 2024-08-09
11+
discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/discussions/1037
12+
updated: 2024-01-08
13+
---
14+
15+
## Abstract
16+
The current protocol buffer API definitions are technically correct, but lack
17+
usable or useful specification. We should add, in comments compatible with
18+
protoc-gen-doc, specification text that clearly states both requirement and
19+
expectation for every message, file, and field. This documentation should be
20+
automatically transformed to markdown documentation that is published to the
21+
Hedera API site. In the ideal case this specification will be sufficient for
22+
any qualified team to implement a completely independent consensus node that
23+
is fully interoperable with the current consensus node software.
24+
25+
## Motivation
26+
The existing protocol buffer API documentation is brief, entirely descriptive,
27+
and often inaccurate. This produces two negative consequences. First, it is not
28+
possible to produce a compatible independent implementation of the Hedera
29+
consensus node software without extensive reference to the existing source
30+
code. Second, developers are often unclear how best to interact with the
31+
Hedera API, and independent SDK developers, in particular, may struggle to
32+
correctly implement these API calls.
33+
34+
As part of expanding the Hedera ecosystem we MUST reduce the difficulty and
35+
hurdles for independent developers when building systems that interact with
36+
the Hedera network. Clear and accurate API specifications are one element
37+
required to accomplish this goal.
38+
39+
## Rationale
40+
This HIP improves the developer experience and enhances decentralization by
41+
making it easier to design distributed applications or alternative
42+
implementations of core network systems.
43+
44+
The use of a markdown format that is automatically generated from the
45+
functional protocol buffer definition files encourages more frequent updates
46+
that are more closely tied to the functional updates to the API documents, and
47+
reduces the inevitable "drift" between functional API and API specification.
48+
49+
## User stories
50+
- As a dApp developer I want to have clear and accurate specification for all
51+
Hedera APIs so that I can confidently design my application to call those
52+
APIs.
53+
- As an independent implementor I want to have clear and accurate specification
54+
for all Hedera APIs so that I can design an independent, correct, and
55+
compatible implementation of Hedera network nodes, including a consensus node.
56+
- As an Hedera software contributor I want to have clear and accurate
57+
specification for all Hedera APIs so that I can confidently implement changes
58+
to Hedera-led software.
59+
- As a dApp developer that receives bytes or is expected to parse, produce, or
60+
process bytes representing a HAPI protobuf message I want to have a clear
61+
specification of the structure and implications of the corresponding proto
62+
messages to understand how to correctly parse them.
63+
64+
## Specification
65+
The core of this HIP is
66+
[the guidelines](../assets/hip-1037/Specification-Format-Style-Guidelines.md)
67+
recommended for this, and all future Hedera protocol buffer specifications.
68+
This HIP, however, also implements sweeping changes to specification text for
69+
the existing API documents. These changes affect over 20,000 lines of text
70+
across almost 150 files in order to add full specification text that complies
71+
with the guidelines expressed in this improvement proposal. The full reference
72+
implementation, therefore, is only linked here for brevity and clarity.<br/>
73+
The implementation of this HIP is detailed in github as a
74+
pull request linked [later in this document](#reference-implementation).
75+
76+
## Backwards Compatibility
77+
This HIP does not change any functional characteristic, and documents the
78+
state of the API as-is. This does not introduce any change in compatibility.
79+
80+
## Security Implications
81+
This HIP updates and clarifies specification and expectation for the Hedera
82+
API. This does not materially impact the security of the system.
83+
84+
## How to Teach This
85+
The Hedera API is a critical component of the design and interaction for the
86+
Hedera ecosystem. Improvements to the formality and completeness of the API
87+
specification help everyone involved to develop distributed applications
88+
more quickly and with greater confidence.
89+
90+
## Reference Implementation
91+
We have a
92+
[pull request](https://github.com/hashgraph/hedera-protobufs/pull/388)
93+
that implements these guidelines across the full hedera-protobufs repository.
94+
95+
## Rejected Ideas
96+
1. Use of a highly formal "language" for specification
97+
* This was deemed excessive. Protocol Buffers are already a highly formal
98+
language, and adding specification as markdown comments, using the
99+
light weight RFC/HIP language is sufficient while remaining approachable
100+
for the largest practical number of community members.
101+
1. Addition of specialized "tag" elements to specification comments.
102+
* This would have required building a complete custom documentation
103+
processor and would have been non-standard. Rather than do so we chose
104+
to adhere closely to existing standard approaches for protocol buffers.
105+
106+
107+
## Open Issues
108+
None.
109+
110+
## References
111+
- Protocol Buffer Document Generator
112+
[protoc-gen-doc](https://github.com/pseudomuto/protoc-gen-doc/?tab=readme-ov-file#protoc-gen-doc).
113+
114+
## Copyright/license
115+
This document is licensed under the Apache License, Version 2.0 --
116+
see [LICENSE](../LICENSE) or (https://www.apache.org/licenses/LICENSE-2.0)
117+

‎HIP/hip-1049.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -6,11 +6,11 @@ requested-by: Hashgraph
66
type: Standards Track
77
category: Service
88
needs-tsc-approval: Yes
9-
status: Last Call
9+
status: Accepted
1010
last-call-date-time: 2024-11-05T07:00:00Z
1111
created: 2024-09-19
1212
discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/pull/1049
13-
updated: 2024-10-22
13+
updated: 2024-11-06
1414
---
1515

1616
## Abstract

0 commit comments

Comments
 (0)