Skip to content

Commit

Permalink
Proposed github process modification.
Browse files Browse the repository at this point in the history
This proposed modification adds detail for how to handle
specification text that is excessively large, and would only
obscure the substance of a HIP if included inline.
* Remove two obsolete copied files (both are still present in
  the `hip` folder, and were identical to those versions).
* Clean up the README file, wrap long lines for readbility,
  and fix some typographic issues.
* Clean up the hip-0000-template.md file, wrap long lines
  for readability (and to encourage the same in HIP documents),
  and fix some typographic issues
* Added content to the "Specification" section to describe a
  recommended method for handling excessively large
  specification text, along with a small example.
* Added a folder and sample file (copied from HIP-904
  implementation) to support the example.

Signed-off-by: Joseph Sinclair <joseph.sinclair@swirldslabs.com>
  • Loading branch information
jsync-swirlds committed Sep 20, 2024
1 parent da405ee commit a3bea7c
Show file tree
Hide file tree
Showing 5 changed files with 254 additions and 398 deletions.
91 changes: 59 additions & 32 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,66 +4,93 @@
[![](https://img.shields.io/badge/view-published-blue)](https://hips.hedera.com)

## Submit a HIP

1. Fork this repository
2. Fill out this template: [hip template](hip-0000-template.md)
3. Create a pull request against hashgraph/hedera-improvement-proposal main

But what category do I make my HIP? See [hip-1 HIP types](HIP/hip-1.md#hip-types)

See [hip-1](HIP/hip-1.md) for details on the HIP process or watch [this video](https://www.youtube.com/watch?v=Gbk8EbtibA0)
1. Fill out this template: [hip template](hip-0000-template.md)
1. If the proposal contains exceptionally large specification text,
particularly API changes or source code, place those changes
in `assets` and link them as described in the template document.
1. Create a pull request against hashgraph/hedera-improvement-proposal main
<dl>
<dt>But what category do I make my HIP?</dt>
<dd>See <a href="HIP/hip-1.md#hip-types">hip-1 HIP types</a>.</dd>
</dl>

See [hip-1](HIP/hip-1.md) for details on the HIP process or watch
[this video](https://www.youtube.com/watch?v=Gbk8EbtibA0)

## What is a HIP?

HIP stands for "Hedera Improvement Proposal". These improvement proposals can range from core protocol changes, to the applications, frameworks, and protocols built on top of the Hedera public network and used by the community. The HIP author is responsible for building consensus within the community and documenting dissenting opinions, as well as tracking their HIP through the process outlined below.
HIP stands for "Hedera Improvement Proposal". These improvement proposals can
range from core protocol changes, to the applications, frameworks, and protocols
built on top of the Hedera public network and used by the community. The HIP
author is responsible for building consensus within the community and
documenting dissenting opinions, as well as tracking their HIP through
the process outlined below.

You can see the list of all HIPs on [the official HIPs site](https://hips.hedera.com).

## What is Hedera Hashgraph?

[Hedera Hashgraph](https://hedera.com) is the only public network built on top of [Dr. Leemon Baird](http://www.leemon.com/)’s [Hashgraph consensus algorithm](http://www.leemon.com/papers/2016b.pdf). Hedera goes beyond blockchain to provide the fast, fair, and secure environment needed to enable enterprise adoption of distributed ledger technologies. You can learn more about Hedera by [reading the Hedera whitepaper](https://hedera.com/whitepaper), and for a more detailed understanding of the Hashgraph Consensus Algorithm you can check out the [hashgraph algorithm whitepaper](http://www.leemon.com/papers/2016b.pdf).
[Hedera Hashgraph](https://hedera.com) is the only public network built on top
of [Dr. Leemon Baird](http://www.leemon.com/)’s
[Hashgraph consensus algorithm](http://www.leemon.com/papers/2016b.pdf).
Hedera goes beyond blockchain to provide the fast, fair, and secure environment
needed to enable enterprise adoption of distributed ledger technologies. You
can learn more about Hedera by
[reading the Hedera whitepaper](https://hedera.com/whitepaper), and for a more
detailed understanding of the Hashgraph Consensus Algorithm you can check out
the [hashgraph algorithm whitepaper](http://www.leemon.com/papers/2016b.pdf).

## Purpose

The goal of HIPs is to have a place to propose new features, to collect community thoughts and input on a particular issue, and further to document all these subject matters in one place. It’s a great way to document these discussions and proposals [here on GitHub](https://github.com/hashgraph/hedera-improvement-proposal), because any [revisions made on these text files will be recorded](https://github.com/hashgraph/hedera-improvement-proposal/commits/master).
The goal of HIPs is to have a place to propose new features, to collect
community thoughts and input on a particular issue, and further to document
all these subject matters in one place. It’s a great way to document these
discussions and proposals
[here on GitHub](https://github.com/hashgraph/hedera-improvement-proposal),
because any
[revisions made on these text files will be recorded](https://github.com/hashgraph/hedera-improvement-proposal/commits/master).

## Qualifications

Each HIP should only be one single key proposal and/or idea. The idea should be focused and only issue to one subject matter to be successful. A HIP must meet certain minimum criteria: it must be clear and have a complete description of the proposed enhancement, the enhancement must represent a net improvement, the proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.
Each HIP should only be one single key proposal and/or idea. The idea should be
focused and only issue to one subject matter to be successful. A HIP must meet
certain minimum criteria: it must be clear and have a complete description of
the proposed enhancement, the enhancement must represent a net improvement,
the proposed implementation, if applicable, must be solid and must not
complicate the protocol unduly.

## Before Submitting

1. Evaluate your idea: consider why you’d like to request changes or improvements, and how it benefits the Hedera Hashgraph community.

2. Thoroughly look through those proposals already submitted to ensure there are no duplicates.

3. Ask the Hedera Hashgraph community first if your idea is original, or has already been through the HIP process.

4. Reevaluate your proposal to ensure sure the idea is applicable to the entire community and not just to one particular author, application, project, or protocol.
1. Evaluate your idea: consider why you’d like to request changes or
improvements, and how it benefits the Hedera Hashgraph community.
1. Thoroughly look through those proposals already submitted to ensure there
are no duplicates.
1. Ask the Hedera Hashgraph community first if your idea is original, or has
already been through the HIP process.
1. Reevaluate your proposal to ensure sure the idea is applicable
to the entire community and not just to one particular author, application,
project, or protocol.

## Local Jekyll Site

Pre-requisites:

- `ruby`: `2.7.8p225`
- `gem`: `3.4.10`
- `bundler`: `1.17.3`

You can run a local version of the HIPs dashboard site:

```shell
bundle install
bundle exec jekyll serve --livereload
```

The site will be available on `http://localhost:4000`.

You can read more about Jekyll on its official [website](https://jekyllrb.com/)

##### Note

An excellent place to discuss your proposal and get feedback is in the [issues section of this repository](https://github.com/hashgraph/hip/issues), or on [Hedera's Discord Server](https://hedera.com/discord); there you can start formalizing the language around your HIP and ensuring it has broad community support.
An excellent place to discuss your proposal and get feedback is in the
[issues section of this repository](https://github.com/hashgraph/hip/issues),
or on [Hedera's Discord Server](https://hedera.com/discord); there you can
start formalizing the language around your HIP and ensuring it has broad
community support.

## Disclaimer(s):

These proposals and discussions have no effect regarding private (permissioned) implementations of the Hashgraph consensus algorithm; additionally, this repository and it’s contents are run by the Hedera Hashgraph community, which means they do not necessarily reflect the views and opinions of Hedera Hashgraph LLC.
These proposals and discussions have no effect regarding private (permissioned)
implementations of the Hashgraph consensus algorithm; additionally, this
repository and it’s contents are run by the Hedera Hashgraph community, which
means they do not necessarily reflect the views and opinions of
Hedera Hashgraph LLC.
117 changes: 117 additions & 0 deletions assets/hip-0000-template/sample.proto
Original file line number Diff line number Diff line change
@@ -0,0 +1,117 @@
/**
* # Token Airdrop
* Messages used to implement a transaction to "airdrop" tokens.<br/>
* An "airdrop" is a distribution of tokens from a funding account
* to one or more recipient accounts, ideally with no action required
* by the recipient account(s).
*
* ### Keywords
* The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
* "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
* document are to be interpreted as described in
* [RFC2119](https://www.ietf.org/rfc/rfc2119) and clarified in
* [RFC8174](https://www.ietf.org/rfc/rfc8174).
*/
syntax = "proto3";

package proto;

/*
* Copyright (C) 2024 Hedera Hashgraph, LLC
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/

option java_package = "com.hederahashgraph.api.proto.java";
// <<<pbj.java_package = "com.hedera.hapi.node.token">>> This comment is special code for setting PBJ Compiler java package
option java_multiple_files = true;

import "basic_types.proto";

/**
* Airdrop one or more tokens to one or more accounts.
*
* ### Effects
* This distributes tokens from the balance of one or more sending account(s)
* to the balance of one or more recipient accounts. Accounts MAY receive the
* tokens in one of four ways.
*
* - An account already associated to the token to be distributed SHALL
* receive the airdropped tokens immediately to the recipient account
* balance.<br/>
* The fee for this transfer SHALL include the transfer, the airdrop fee,
* and any custom fees.
* - An account with available automatic association slots SHALL be
* automatically associated to the token, and SHALL immediately receive
* the airdropped tokens to the recipient account balance.<br/>
* The fee for this transfer SHALL include the transfer, the association,
* the cost to renew that association once, the airdrop fee, and
* any custom fees.
* - An account with "receiver signature required" set SHALL have a
* "Pending Airdrop" created and must claim that airdrop with a
* `claimAirdrop` transaction.<br/>
* The fee for this transfer SHALL include the transfer, the association,
* the cost to renew that association once, the airdrop fee, and
* any custom fees.<br/>
* If the pending airdrop is not claimed immediately, the `sender` SHALL
* pay the cost to renew the token association, and the cost to maintain
* the pending airdrop, until the pending airdrop is claimed or cancelled.
* - An account with no available automatic association slots SHALL have a
* "Pending Airdrop" created and must claim that airdrop with a
* `claimAirdrop` transaction.<br/>
* The fee for this transfer SHALL include the transfer, the association,
* the cost to renew that association once, the airdrop fee, and any custom
* fees.<br/>
* If the pending airdrop is not claimed immediately, the `sender` SHALL
* pay the cost to renew the token association, and the cost to maintain
* the pending airdrop, until the pending airdrop is claimed or cancelled.
*
* If an airdrop would create a pending airdrop for a fungible/common token,
* and a pending airdrop for the same sender, receiver, and token already
* exists, the existing pending airdrop SHALL be updated to add the new
* amount to the existing airdrop, rather than creating
* a new pending airdrop.<br/>
* Any airdrop that completes immediately SHALL be irreversible. Any airdrop
* that results in a "Pending Airdrop" MAY be canceled via a `cancelAirdrop`
* transaction.<br/>
* All transfer fees (including custom fees and royalties), as well as the
* rent cost for the first auto-renewal period for any automatic-association
* slot occupied by the airdropped tokens, SHALL be charged to the account
* paying for this transaction.<br/>
*
* ### Block Stream Effects
* - Each successful transfer SHALL be recorded in `token_transfer_list`
* for the transaction record.
* - Each successful transfer that consumes an automatic association slot
* SHALL populate the `automatic_association` field for the record.
* - Each pending transfer _created_ SHALL be added to the
* `pending_airdrops` field for the record.
* - Each pending transfer _updated_ SHALL be added to the
* `pending_airdrops` field for the record.
*/
message TokenAirdropTransactionBody {
/**
* A list of token transfers representing one or more airdrops.
* <p>
* The sender for each transfer MUST have sufficient balance to complete
* the transfers.<br/>
* All token transfers MUST successfully transfer tokens or create a
* pending airdrop for this transaction to succeed.<br/>
* This list MUST contain between 1 and 10 transfers, inclusive.
* <p>
* Note that each transfer of fungible/common tokens requires both a debit
* and a credit, so each _fungible_ token transfer MUST have _balanced_
* entries in the TokenTransferList for that transfer.
*/
repeated TokenTransferList token_transfers = 1;
}
Loading

0 comments on commit a3bea7c

Please sign in to comment.