You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 18, 2025. It is now read-only.
> This guide is meant for local development and contributing to the repository only, for guidance on the TIPs process and how to propose Tangle improvements, please see the [README](README.md)
3
+
4
+
5
+
# Documentation
6
+
7
+
The TIPs online documentation is built using [Docusaurus 2](https://docusaurus.io/). The deployment is done through a centralized build from [IOTA WIKI](https://github.com/iota-wiki/iota-wiki). To run a local instance, the [IOTA WIKI CLI](https://www.npmjs.com/package/@iota-wiki/cli) is used.
8
+
9
+
## Prerequisites
10
+
11
+
-[Node.js 16.10 or above](https://nodejs.org/en/download/).
12
+
-[Modern Yarn](https://yarnpkg.com/getting-started/install) enabled by running `corepack enable`.
13
+
14
+
## Installation
15
+
16
+
```console
17
+
yarn
18
+
```
19
+
20
+
This command installs all necessary dependencies.
21
+
22
+
## Local Development
23
+
24
+
```console
25
+
yarn start
26
+
```
27
+
28
+
This command starts a local, wiki themed development server and opens up a browser window. Most changes are reflected live without having to restart the server.
Copy file name to clipboardExpand all lines: README.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,7 @@ Building the IOTA ecosystem is a community effort, therefore we welcome anyone t
8
8
9
9
Do you have an idea how to improve the IOTA technology stack?
10
10
- Head over to the [discussions](https://github.com/iotaledger/tips/discussions) page to browse already submitted ideas or share yours!
11
-
- Once your idea is discussed, you can submit a draft TIP ([template here](./tip-template.md)) as a PR to the repository.
11
+
- Once your idea is discussed, you can submit a draft TIP ([template here](https://github.com/iotaledger/tips/blob/main/tip-template.md) as a PR to the repository.
12
12
- You will receive feedback from the TIP Editors and review from core devs.
13
13
- Once accepted, your TIP is merged as Draft.
14
14
- It is your responsibility to drive its implementation and to present a clear plan on how the new feature will be adopted by the network.
Copy file name to clipboardExpand all lines: tips/TIP-0004/tip-0004.md
+3-3
Original file line number
Diff line number
Diff line change
@@ -59,13 +59,13 @@ In the following we define the Merkle tree hash (MTH) function that returns the
59
59
- The output is a single 32-byte hash.
60
60
61
61
Given an ordered list of n input strings D<sub>n</sub> = {d<sub>1</sub>, d<sub>2</sub>, ..., d<sub>n</sub>}, the Merkle tree hash of D is defined as follows:
62
-
- If D is an empty list, MTH(D) is the hash of an empty string:<br>
62
+
- If D is an empty list, MTH(D) is the hash of an empty string:<br/>
63
63
MTH({}) = BLAKE2().
64
-
- If D has the length 1, the hash (also known as a leaf hash) is:<br>
64
+
- If D has the length 1, the hash (also known as a leaf hash) is:<br/>
Note that the hash calculations for leaves and nodes differ. This is required to provide second preimage resistance: Without such a prefix, for a given input D an attacker could replace two (or more) leaves with their corresponding aggregated node hash without changing the final value of MTH(D). This violates the fundamental assumption that, given MTH(D), it should be practically impossible to find a different input D' leading to the same value. Adding a simple prefix mitigates this issue, since now leaf and node hashes are computed differently and can no longer be interchanged.
Copy file name to clipboardExpand all lines: tips/TIP-0012/tip-0012.md
+2-2
Original file line number
Diff line number
Diff line change
@@ -16,8 +16,8 @@ The IOTA protocol uses proof-of-work as a means to rate-limit the network. Curre
16
16
17
17
# Motivation
18
18
19
-
In the current IOTA Protocol, each transaction has a fixed size of 8019 trits and is hashed using Curl-P-81 to compute its 243-trit transaction hash, where the PoW's difficulty equals the number of trailing zero trits in that hash.<br>
20
-
Unfortunately, the performance of Curl-P-81 is slow, achieving only about 2 MB/s on a single core. This would make the PoW validation a bottleneck, especially for high usage scenarios with larger messages. Thus, this RFC proposes a two-stage approach to speed up the validation process: First, the [BLAKE2b-256](https://tools.ietf.org/html/rfc7693) hash function is used to create a short, fixed length digest of the message. Then, this digest, together with the nonce, is hashed using Curl-P-81. Since the digest only needs to be computed once while iterating over different nonce values, this preserves Curl as the PoW-relevant hash. However, the validation is much faster, as BLAKE2b-256 has a performance of about 1 GB/s and Curl then only needs to be executed for one single 243-trit block of input. Since the input of the final Curl computation is always fixed, parallel Curl variants can be used in this stage to further speed up the validation if necessary.<br>
19
+
In the current IOTA Protocol, each transaction has a fixed size of 8019 trits and is hashed using Curl-P-81 to compute its 243-trit transaction hash, where the PoW's difficulty equals the number of trailing zero trits in that hash.<br/>
20
+
Unfortunately, the performance of Curl-P-81 is slow, achieving only about 2 MB/s on a single core. This would make the PoW validation a bottleneck, especially for high usage scenarios with larger messages. Thus, this RFC proposes a two-stage approach to speed up the validation process: First, the [BLAKE2b-256](https://tools.ietf.org/html/rfc7693) hash function is used to create a short, fixed length digest of the message. Then, this digest, together with the nonce, is hashed using Curl-P-81. Since the digest only needs to be computed once while iterating over different nonce values, this preserves Curl as the PoW-relevant hash. However, the validation is much faster, as BLAKE2b-256 has a performance of about 1 GB/s and Curl then only needs to be executed for one single 243-trit block of input. Since the input of the final Curl computation is always fixed, parallel Curl variants can be used in this stage to further speed up the validation if necessary.<br/>
21
21
Furthermore, it is important to note that the time required to do the PoW depends on the PoW difficulty and not on the message length. As such, to treat messages with different lengths differently, we need to weight the PoW difficulty by the message length.
22
22
23
23
It will be easy to adapt existing hardware and software implementations of the current PoW mechanism to work with the proposed design. Only the input and the position of the nonce in the buffer needs to be adapted. This enables existing Curl projects to continue persisting and also the entire PoW landscape should stay almost the same.
0 commit comments