From 072b73ed3bd3ad3dfca30b59b772b614e326e9d8 Mon Sep 17 00:00:00 2001 From: Dr-Electron Date: Thu, 29 Jun 2023 10:22:25 +0200 Subject: [PATCH 1/8] Add glossary plugin --- package.json | 1 + shimmer/docusaurus.config.js | 9 +++++---- shimmer/jargon.js | 5 +++++ src/common/defaultContentPlugin.js | 27 +++++++++++++++++---------- src/utils/config.js | 15 ++++++++------- yarn.lock | 26 +++++++++++++++++++++++++- 6 files changed, 61 insertions(+), 22 deletions(-) create mode 100644 shimmer/jargon.js diff --git a/package.json b/package.json index 641c2c5d8f1..b152e2e1455 100644 --- a/package.json +++ b/package.json @@ -70,6 +70,7 @@ "react-player": "^2.11.2", "react-popper": "^2.3.0", "react-select": "^5.2.2", + "rehype-jargon": "^2.22.2", "rehype-katex": "4", "rehype-lodash-template": "^0.2.1", "remark-code-import": "^0.4.0", diff --git a/shimmer/docusaurus.config.js b/shimmer/docusaurus.config.js index f307c99edad..701a5f56907 100644 --- a/shimmer/docusaurus.config.js +++ b/shimmer/docusaurus.config.js @@ -2,11 +2,11 @@ const path = require('path'); const contentConfigs = require('./contentPlugins'); const { create_doc_plugin, globStatic } = require('../src/utils/config'); -const contentPlugins = contentConfigs.map((contentConfig) => - create_doc_plugin(contentConfig), -); - module.exports = async () => { + const contentPlugins = await Promise.all(contentConfigs.map(async (contentConfig) => + await create_doc_plugin(contentConfig), + )); + //console.log(contentPlugins); const staticDirs = await globStatic('/docs/**/static/', __dirname); return { @@ -222,3 +222,4 @@ module.exports = async () => { staticDirectories: [...staticDirs], }; }; + diff --git a/shimmer/jargon.js b/shimmer/jargon.js new file mode 100644 index 00000000000..3cddd29889f --- /dev/null +++ b/shimmer/jargon.js @@ -0,0 +1,5 @@ +module.exports = { + rehype: "rehype is a tool that transforms HTML with plugins. These plugins can inspect and change the HTML. You can use rehype on the server, the client, CLIs, deno, etc.", + freesewing: "FreeSewing is an open source platform for made-to-measure sewing patterns. See freesewing.org", + iota: "Test" +} \ No newline at end of file diff --git a/src/common/defaultContentPlugin.js b/src/common/defaultContentPlugin.js index a2ae6e92a0b..1bab40aac5b 100644 --- a/src/common/defaultContentPlugin.js +++ b/src/common/defaultContentPlugin.js @@ -1,12 +1,19 @@ /** @type {import('@docusaurus/plugin-content-docs').Options} */ -module.exports = { - editUrl: 'https://github.com/iotaledger/iota-wiki/edit/main/', - showLastUpdateTime: true, - remarkPlugins: [ - require('remark-math'), - require('remark-code-import'), - require('remark-import-partial'), - require('remark-remove-comments'), - ], - rehypePlugins: [require('rehype-katex')], +module.exports = async() => { + const jargonPlugin = (await import('rehype-jargon')).default; + + return { + editUrl: 'https://github.com/iotaledger/iota-wiki/edit/main/', + showLastUpdateTime: true, + remarkPlugins: [ + require('remark-math'), + require('remark-code-import'), + require('remark-import-partial'), + require('remark-remove-comments'), + ], + rehypePlugins: [ + require('rehype-katex'), + jargonPlugin, + ], + } }; diff --git a/src/utils/config.js b/src/utils/config.js index e98862eb546..2d76a5f4955 100644 --- a/src/utils/config.js +++ b/src/utils/config.js @@ -110,13 +110,14 @@ async function globStatic(pattern, cwd = __dirname) { * Create a section * @param {import('@docusaurus/plugin-content-docs').Options} options */ -function create_doc_plugin({ ...options }) { - const clone = { ...defaultSettings }; +async function create_doc_plugin({ ...options }) { + const setting = await defaultSettings(); + // Check if options has a rehypePlugin array if (options.rehypePlugins) { // If it does, add it to the clone and delete it from options - clone.rehypePlugins = defaultSettings.rehypePlugins.concat( - options.rehypePlugins, + setting.rehypePlugins.push( + ...options.rehypePlugins ); delete options.rehypePlugins; } @@ -124,8 +125,8 @@ function create_doc_plugin({ ...options }) { // Check if options has a remarkPlugins array if (options.remarkPlugins) { // If it does, add it to the clone and delete it from options - clone.remarkPlugins = defaultSettings.remarkPlugins.concat( - options.remarkPlugins, + setting.remarkPlugins.push( + ...options.remarkPlugins ); delete options.remarkPlugins; } @@ -134,7 +135,7 @@ function create_doc_plugin({ ...options }) { '@docusaurus/plugin-content-docs', /** @type {import('@docusaurus/plugin-content-docs').Options} */ ({ - ...clone, + ...setting, ...options, }), ]; diff --git a/yarn.lock b/yarn.lock index 75e321bcea2..2445b70b93d 100644 --- a/yarn.lock +++ b/yarn.lock @@ -2748,6 +2748,7 @@ __metadata: react-player: ^2.11.2 react-popper: ^2.3.0 react-select: ^5.2.2 + rehype-jargon: ^2.22.2 rehype-katex: 4 rehype-lodash-template: ^0.2.1 remark-code-import: ^0.4.0 @@ -9829,6 +9830,19 @@ __metadata: languageName: node linkType: hard +"hast-util-from-html@npm:^1.0.0": + version: 1.0.2 + resolution: "hast-util-from-html@npm:1.0.2" + dependencies: + "@types/hast": ^2.0.0 + hast-util-from-parse5: ^7.0.0 + parse5: ^7.0.0 + vfile: ^5.0.0 + vfile-message: ^3.0.0 + checksum: 81cbda7dfa4c02fcb4e4359a48e25ebee7bef133dc607c2c036c53df27efacdfa22313a86398391ef22b31decda98c7110f1b441c5a48f419514be6b5d4b5603 + languageName: node + linkType: hard + "hast-util-from-parse5@npm:^6.0.0": version: 6.0.1 resolution: "hast-util-from-parse5@npm:6.0.1" @@ -15173,6 +15187,16 @@ plugin-image-zoom@flexanalytics/plugin-image-zoom: languageName: node linkType: hard +"rehype-jargon@npm:^2.22.2": + version: 2.22.2 + resolution: "rehype-jargon@npm:2.22.2" + dependencies: + hast-util-from-html: ^1.0.0 + unist-util-visit: ^4.1.0 + checksum: e241df1b404e6f85521a54db5afa172b0e219aff8ba8a210dc94cbde01b1dc63d59b3be42d6a07d6cb8ee2b84b380820cdb8bc45920b660973f5361f931c853c + languageName: node + linkType: hard + "rehype-katex@npm:4": version: 4.0.0 resolution: "rehype-katex@npm:4.0.0" @@ -17565,7 +17589,7 @@ plugin-image-zoom@flexanalytics/plugin-image-zoom: languageName: node linkType: hard -"unist-util-visit@npm:^4.0.0": +"unist-util-visit@npm:^4.0.0, unist-util-visit@npm:^4.1.0": version: 4.1.2 resolution: "unist-util-visit@npm:4.1.2" dependencies: From 80d7ee32dbf184d33dc020c0a9be3bd9fb2eaaa8 Mon Sep 17 00:00:00 2001 From: Dr-Electron Date: Sat, 8 Jul 2023 23:10:27 +0200 Subject: [PATCH 2/8] Fix rehype-jargon --- package.json | 2 +- shimmer/docusaurus.config.js | 9 ++-- shimmer/jargon.js | 10 ++-- shimmer/learn/governance/governance-scope.md | 2 +- src/common/css/custom.css | 42 ++++++++++++++++ src/common/defaultContentPlugin.js | 7 +-- src/utils/config.js | 8 +--- yarn.lock | 50 ++++++++++---------- 8 files changed, 86 insertions(+), 44 deletions(-) diff --git a/package.json b/package.json index b152e2e1455..149239ad318 100644 --- a/package.json +++ b/package.json @@ -70,7 +70,7 @@ "react-player": "^2.11.2", "react-popper": "^2.3.0", "react-select": "^5.2.2", - "rehype-jargon": "^2.22.2", + "rehype-jargon": "3.0.0-alpha.0", "rehype-katex": "4", "rehype-lodash-template": "^0.2.1", "remark-code-import": "^0.4.0", diff --git a/shimmer/docusaurus.config.js b/shimmer/docusaurus.config.js index 701a5f56907..d94cf557786 100644 --- a/shimmer/docusaurus.config.js +++ b/shimmer/docusaurus.config.js @@ -3,9 +3,11 @@ const contentConfigs = require('./contentPlugins'); const { create_doc_plugin, globStatic } = require('../src/utils/config'); module.exports = async () => { - const contentPlugins = await Promise.all(contentConfigs.map(async (contentConfig) => - await create_doc_plugin(contentConfig), - )); + const contentPlugins = await Promise.all( + contentConfigs.map( + async (contentConfig) => await create_doc_plugin(contentConfig), + ), + ); //console.log(contentPlugins); const staticDirs = await globStatic('/docs/**/static/', __dirname); @@ -222,4 +224,3 @@ module.exports = async () => { staticDirectories: [...staticDirs], }; }; - diff --git a/shimmer/jargon.js b/shimmer/jargon.js index 3cddd29889f..e2570dcaa70 100644 --- a/shimmer/jargon.js +++ b/shimmer/jargon.js @@ -1,5 +1,7 @@ module.exports = { - rehype: "rehype is a tool that transforms HTML with plugins. These plugins can inspect and change the HTML. You can use rehype on the server, the client, CLIs, deno, etc.", - freesewing: "FreeSewing is an open source platform for made-to-measure sewing patterns. See freesewing.org", - iota: "Test" -} \ No newline at end of file + rehype: + 'rehype is a tool that transforms HTML with plugins. These plugins can inspect and change the HTML. You can use rehype on the server, the client, CLIs, deno, etc.', + freesewing: + 'FreeSewing is an open source platform for made-to-measure sewing patterns. See freesewing.org', + iota: 'Test', +}; diff --git a/shimmer/learn/governance/governance-scope.md b/shimmer/learn/governance/governance-scope.md index 1bf103a03ad..b10719c2dc9 100644 --- a/shimmer/learn/governance/governance-scope.md +++ b/shimmer/learn/governance/governance-scope.md @@ -10,7 +10,7 @@ keywords: ## Parameters that are open for Community Governance in Shimmer -(Defined by the IOTA Foundation) +(Defined by the _IOTA_ Foundation) This list will be extended with the maturity of the Shimmer protocol by the IF engineering Team with the goal to open more programmable parameters to governance. diff --git a/src/common/css/custom.css b/src/common/css/custom.css index 4c4f1b49345..ee8984da045 100644 --- a/src/common/css/custom.css +++ b/src/common/css/custom.css @@ -28,6 +28,48 @@ background-color: var(--ifm-color-primary); } +/*------------Jargon---------------*/ +/* Add a dashed line under jargon terms */ +.jargon-term { + text-decoration: underline var(--ifm-color-primary-light); +} +/* Add a question mark behind/above jargon terms */ +.jargon-term::after { + content: '?'; + font-weight: bold; + display: inline-block; + transform: translate(0, -0.5em); + font-size: 75%; + color: var(--ifm-color-primary-light); + margin-left: 3px; +} +/* Hover behavior for the therm itself */ +.jargon-term:hover { + position: relative; + text-decoration: none; + cursor: help; +} +/* Hide info by default */ +.jargon-term .jargon-info { + display: none; +} +/* Show info on hover */ +.jargon-term:hover .jargon-info { + display: block; + position: absolute; + top: 1.5em; + left: 0; + background: var(--ifm-hover-overlay); + border: 1px solid var(--ifm-color-primary-light); + padding: 1rem; + border-radius: 4px; + font-size: 90%; + /*min-width: 250px;*/ + max-width: 450px; + z-index: 1; +} +/*---------------------------------*/ + .post > .menu__link::before { content: 'post'; background-color: var(--openapi-code-green); diff --git a/src/common/defaultContentPlugin.js b/src/common/defaultContentPlugin.js index 1bab40aac5b..84e6d46051e 100644 --- a/src/common/defaultContentPlugin.js +++ b/src/common/defaultContentPlugin.js @@ -1,6 +1,7 @@ /** @type {import('@docusaurus/plugin-content-docs').Options} */ -module.exports = async() => { +module.exports = async () => { const jargonPlugin = (await import('rehype-jargon')).default; + const jargonConfig = (await import('./../../shimmer/jargon.js')).default; return { editUrl: 'https://github.com/iotaledger/iota-wiki/edit/main/', @@ -13,7 +14,7 @@ module.exports = async() => { ], rehypePlugins: [ require('rehype-katex'), - jargonPlugin, + [jargonPlugin, { jargon: jargonConfig }], ], - } + }; }; diff --git a/src/utils/config.js b/src/utils/config.js index 2d76a5f4955..f72e4e65d5f 100644 --- a/src/utils/config.js +++ b/src/utils/config.js @@ -116,18 +116,14 @@ async function create_doc_plugin({ ...options }) { // Check if options has a rehypePlugin array if (options.rehypePlugins) { // If it does, add it to the clone and delete it from options - setting.rehypePlugins.push( - ...options.rehypePlugins - ); + setting.rehypePlugins.push(...options.rehypePlugins); delete options.rehypePlugins; } // Check if options has a remarkPlugins array if (options.remarkPlugins) { // If it does, add it to the clone and delete it from options - setting.remarkPlugins.push( - ...options.remarkPlugins - ); + setting.remarkPlugins.push(...options.remarkPlugins); delete options.remarkPlugins; } diff --git a/yarn.lock b/yarn.lock index 2445b70b93d..7a9fcf9b9fd 100644 --- a/yarn.lock +++ b/yarn.lock @@ -2748,7 +2748,7 @@ __metadata: react-player: ^2.11.2 react-popper: ^2.3.0 react-select: ^5.2.2 - rehype-jargon: ^2.22.2 + rehype-jargon: 3.0.0-alpha.0 rehype-katex: 4 rehype-lodash-template: ^0.2.1 remark-code-import: ^0.4.0 @@ -4807,9 +4807,9 @@ __metadata: linkType: hard "@types/node@npm:*": - version: 20.4.0 - resolution: "@types/node@npm:20.4.0" - checksum: 8ad632ee131611651fc5f4ac3a47427640e2492ab314fe1c4d0c3b97af71784ef48c53221d5f9922aab4724375dcb4f33137b3107ba2c356d9366216a31678aa + version: 20.4.1 + resolution: "@types/node@npm:20.4.1" + checksum: 22cbcc792f2eb636fe4188778ed0f32658ab872aa7fcb9847b3fa289a42b14b9f5e30c6faec50ef3c7adbc6c2a246926e5858136bb8b10c035a3fcaa6afbeed2 languageName: node linkType: hard @@ -7420,11 +7420,11 @@ __metadata: linkType: hard "css-declaration-sorter@npm:^6.3.1": - version: 6.4.0 - resolution: "css-declaration-sorter@npm:6.4.0" + version: 6.4.1 + resolution: "css-declaration-sorter@npm:6.4.1" peerDependencies: postcss: ^8.0.9 - checksum: b716bc3d79154d3d618a90bd192533adf6604307c176e25e715a3b7cde587ef16971769fbf496118a376794280edf97016653477936c38c5a74cc852d6e38873 + checksum: cbdc9e0d481011b1a28fd5b60d4eb55fe204391d31a0b1b490b2cecf4baa85810f9b8c48adab4df644f4718104ed3ed72c64a9745e3216173767bf4aeca7f9b8 languageName: node linkType: hard @@ -9526,17 +9526,17 @@ __metadata: linkType: hard "glob@npm:^10.2.2": - version: 10.3.1 - resolution: "glob@npm:10.3.1" + version: 10.3.2 + resolution: "glob@npm:10.3.2" dependencies: foreground-child: ^3.1.0 jackspeak: ^2.0.3 minimatch: ^9.0.1 - minipass: ^5.0.0 || ^6.0.2 - path-scurry: ^1.10.0 + minipass: ^5.0.0 || ^6.0.2 || ^7.0.0 + path-scurry: ^1.10.1 bin: glob: dist/cjs/src/bin.js - checksum: 19c8c2805658b1002fecf0722cd609a33153d756a0d5260676bd0e9c5e6ef889ec9cce6d3dac0411aa90bce8de3d14f25b6f5589a3292582cccbfeddd0e98cc4 + checksum: 3b4f455192d18eb1cf41a9193c825f594a70323b522f290d4b75191d3e399791f9da1febef339392a9828c03a3bf2b96e0b32cc8efb0068c2b11df585026a367 languageName: node linkType: hard @@ -12556,10 +12556,10 @@ __metadata: languageName: node linkType: hard -"minipass@npm:^5.0.0 || ^6.0.2": - version: 6.0.2 - resolution: "minipass@npm:6.0.2" - checksum: d140b91f4ab2e5ce5a9b6c468c0e82223504acc89114c1a120d4495188b81fedf8cade72a9f4793642b4e66672f990f1e0d902dd858485216a07cd3c8a62fac9 +"minipass@npm:^5.0.0 || ^6.0.2 || ^7.0.0": + version: 7.0.1 + resolution: "minipass@npm:7.0.1" + checksum: fedd1293f6a1b4e406c242a1cecfb75d0a81422bb2c365d999e33a88642fb68d70a89d95b550e08c640b3c0d9162829310e0c58b9b846b9218de25779818c709 languageName: node linkType: hard @@ -13592,13 +13592,13 @@ __metadata: languageName: node linkType: hard -"path-scurry@npm:^1.10.0": - version: 1.10.0 - resolution: "path-scurry@npm:1.10.0" +"path-scurry@npm:^1.10.1": + version: 1.10.1 + resolution: "path-scurry@npm:1.10.1" dependencies: lru-cache: ^9.1.1 || ^10.0.0 - minipass: ^5.0.0 || ^6.0.2 - checksum: 3b66a4a6ab66e45755b577c966ecf0da92d3e068b3c992d8f69aa2cc908ef4eda9358253e9b4f86cad43d3ad810ec445be164105975f5cb3fdab68459c59dc6e + minipass: ^5.0.0 || ^6.0.2 || ^7.0.0 + checksum: e2557cff3a8fb8bc07afdd6ab163a92587884f9969b05bbbaf6fe7379348bfb09af9ed292af12ed32398b15fb443e81692047b786d1eeb6d898a51eb17ed7d90 languageName: node linkType: hard @@ -15187,13 +15187,13 @@ plugin-image-zoom@flexanalytics/plugin-image-zoom: languageName: node linkType: hard -"rehype-jargon@npm:^2.22.2": - version: 2.22.2 - resolution: "rehype-jargon@npm:2.22.2" +"rehype-jargon@npm:3.0.0-alpha.0": + version: 3.0.0-alpha.0 + resolution: "rehype-jargon@npm:3.0.0-alpha.0" dependencies: hast-util-from-html: ^1.0.0 unist-util-visit: ^4.1.0 - checksum: e241df1b404e6f85521a54db5afa172b0e219aff8ba8a210dc94cbde01b1dc63d59b3be42d6a07d6cb8ee2b84b380820cdb8bc45920b660973f5361f931c853c + checksum: 6461aa23f1ce9a0f647d58c6d61bb54e141be2a07acea2704de6aaba3b91590cbfcb8404aa824f489cc1bfbe2cb4c35f837b30ca2cd9aa988ce48bf73a45f468 languageName: node linkType: hard From 43357628a02ea24238f97e08794a92f41276c381 Mon Sep 17 00:00:00 2001 From: Dr-Electron Date: Sun, 9 Jul 2023 01:56:07 +0200 Subject: [PATCH 3/8] Add Glossary component --- .github/workflows/build.reusable.yaml | 3 + .gitpod.yml | 1 + README.md | 2 +- common/docusaurus.config.js | 1 + common/jargon.js | 231 ++++++++++++++++++++++++++ package.json | 1 + shimmer/jargon.js | 7 - shimmer/learn/glossary.md | 187 --------------------- shimmer/learn/glossary.mdx | 8 + src/common/css/custom.css | 2 +- src/common/defaultContentPlugin.js | 2 +- theme/package.json | 4 +- theme/src/theme/Glossary/index.tsx | 55 ++++++ yarn.lock | 110 ++++++++++-- 14 files changed, 404 insertions(+), 210 deletions(-) create mode 100644 common/jargon.js delete mode 100644 shimmer/jargon.js delete mode 100644 shimmer/learn/glossary.md create mode 100644 shimmer/learn/glossary.mdx create mode 100644 theme/src/theme/Glossary/index.tsx diff --git a/.github/workflows/build.reusable.yaml b/.github/workflows/build.reusable.yaml index c602351fead..23394fdfb20 100644 --- a/.github/workflows/build.reusable.yaml +++ b/.github/workflows/build.reusable.yaml @@ -38,6 +38,9 @@ jobs: - name: Build plugins run: | yarn build:plugins + - name: Build theme + run: | + yarn build:theme # Submodules cached per environment to save time - name: Cache submodules uses: actions/cache@v3 diff --git a/.gitpod.yml b/.gitpod.yml index b4146b0e807..246ce4b72f6 100644 --- a/.gitpod.yml +++ b/.gitpod.yml @@ -3,6 +3,7 @@ tasks: init: | corepack enable yarn + yarn build:theme && yarn build:plugins yarn build:all command: yarn serve github: diff --git a/README.md b/README.md index 82fce67e352..a71cd108bfa 100644 --- a/README.md +++ b/README.md @@ -69,7 +69,7 @@ To preview the Wiki locally, use the following steps. For more preview and build 1. Clone the repository by running `git clone https://github.com/iota-wiki/iota-wiki.git` and go to the directory with `cd iota-wiki`. 2. Install dependencies with `yarn`. -3. Build plugins once with `yarn build:plugins` +3. Build the theme and all plugins once with `yarn build:theme && yarn build:plugins` 4. Preview a specific environment with `yarn start:` where environment can be `iota`, `shimmer` or `next`. You should always prefer previewing only a specific environment of the Wiki, but if you need a complete Wiki build you can replace step 3 with `yarn start:all`. diff --git a/common/docusaurus.config.js b/common/docusaurus.config.js index 811a70123be..8e232daf970 100644 --- a/common/docusaurus.config.js +++ b/common/docusaurus.config.js @@ -68,6 +68,7 @@ module.exports = { themes: [ 'docusaurus-theme-openapi-docs', '@saucelabs/theme-github-codeblock', + '@iota-wiki/theme', ], staticDirectories: [path.resolve(__dirname, '../static')], }; diff --git a/common/jargon.js b/common/jargon.js new file mode 100644 index 00000000000..70492c7a32c --- /dev/null +++ b/common/jargon.js @@ -0,0 +1,231 @@ +module.exports = { + 'address checksum': + 'Checksum validation is a way to determine if an address is valid and does not contain typos.', + 'dynamic po': + '(In development for IOTA 1.5 and Shimmer): With this feature, the coordinator can issue a milestone and simultaneously set the future PoW score. This means that if the network is not fully utilized, the PoW will be reduced to the point where it can be executed by microdevices. Accordingly, the coordinator can also raise the PoW difficulty in case of high utilization and thus make an attack very expensive.', + 'auto peering': + 'A mechanism that allows nodes to automatically select their neighbors without manual intervention by the node operator.', + 'api(application programming interfaces)': + 'The way for applications to interact with the Tangle.', + 'atomic transactions': + 'Instead of the bundle construct, IOTA and Shimmer use simpler Atomic Transactions. An Atomic Transaction includes everything related to a transaction in a single message instead of splitting it up (Bundles). This reduces network overhead and signature verification load, improves spam protection and rate control, and shortens the length of Merkle proofs (for future sharding). It also reduces implementation overhead and increases maintainability of the core node software.', + 'application layer (iota 2.0)': + 'The top layer of the 3-layer communication protocol. The IOTA protocol allows a variety of external applications to run on the Message Tangle. Anyone can design an application and users can decide which applications to run on their nodes. These applications will all use the communication layer to transmit and store data.', + 'approval switch (iota 2.0)': + 'When a message is selected as a parent, we can choose from the strong or weak tip pool. This mechanism is called Approval Switch.', + 'approval weight (iota 2.0)': + 'A message gets Mana-weight by approving the message directly or indirectly. However, only strong parents can pass on the mana weight to the past, while weak parents receive the weight from their weak children but do not pass it on.', + 'approvers (iota 2.0)': + 'Parents are approved by their referencing messages called approvers. It is thus a reverse mapping of parents. As in the parents definition, an approver might be either strong or weak.', + balance: + 'Funds on the addresses (account). These are always available and cannot be deleted or forgotten.', + 'blockchain bottleneck': + 'The more transactions are issued, the more the block rate and size become a bottleneck in the system. It is no longer possible to capture all incoming transactions in a prompt manner. Attempts to speed up block rates result in more orphaned blocks (blocks are left behind) and reduce the security of the blockchain.', + 'branch (iota 2.0)': + 'A version of the ledger that temporarily coexists with other versions, each spawned by conflicting transactions.', + bee: 'Node software developed by the IOTA foundation using the Rust programming language.', + 'bootstrapping attack': + 'An attack in which a node downloads malicious snapshot files, including invalid transactions and balances.', + curl: 'This is one of the hash functions currently in use. It is based on the "sponge" construction of the Keccak inventors (SHA-3).', + confirmed: + 'Confirmed transactions. Messages in the Tangle are considered for confirmation only when they are directly or indirectly referenced by a milestone that the Coordinator node has validated. To allow the nodes to recognize the milestones, all nodes that participate in the same network are configured with the Merkle root address of a Coordinator that they trust to confirm messages. Using this address, nodes can validate the signatures in milestones to verify whether the trusted Coordinator signs them. To make sure that new messages always have a chance of being confirmed, the Coordinator sends indexed milestones at regular intervals. This way, nodes can compare the indexes of their milestones to check whether they are synchronized with the rest of the network.', + ctps: 'Confirmed transactions per second.', + 'cumulative weight': + 'A system for valuing transactions. Each additional transaction that references a transaction increases its cumulative weight. When tips are selected, a path through transactions that has a higher cumulative weight is preferred.', + chronicle: + "A permanode solution of the IOTA Foundation. It allows to store all transactions reaching a node in a distributed database that is secure and scales well. Chronicle is used to store the Tangle's unlimited data flow and make it queryable. In other words, permanence allows the entire history of the Tangle to be stored indefinitely and makes that data easily accessible.", + consensus: + 'Agreement on a specific date or value in distributed multi-agent systems, in the presence of faulty processes.', + 'coordinator (only up to iota 2.0)': + 'A trusted entity, as protection against malicious transactions. The Tangle is not yet a final product, it is still in beta. The network currently relies on a kind of shield, the so-called coordinator. It is open-source and runs on a Hornet node. The COO acts as a centralized, voluntary, and temporary alternative consensus mechanism for the Tangle. To do this, the COO sends honest transactions to the full nodes at regular intervals. These packets contain a signed message with no value, called a milestone. The full nodes in the Tangle consider a transaction as confirmed only if it is approved by a milestone. Important: The coordinator can only confirm transactions, but he cannot bypass the consensus rules. To create, freeze or steal tokens is not possible for him. This fixed rule and the COO address is hardcoded on each full node, so the coordinator\u2019s influence on the tangle is very limited, since the tangle is also constantly monitored by all the other full nodes. > The Coo will be switched off with the IOTA 2.0 upgrade.', + 'communication layer (iota 2.0)': + 'This layer stores and communicates information. This layer contains the distributed ledger or tangle. The rate control and timestamps are also located in this layer.', + 'core object type (iota 2.0)': + 'An object type that must be parsed by all nodes. Parsers are computer programs responsible for decomposing and converting an input into a format more suitable for further processing.', + 'core application (iota 2.0)': + 'Core application that must be executed by all nodes, for example the value transfer application.', + 'child (iota 2.0)': 'A transaction that gets referenced by Parents.', + chrysalis: 'The name of the IOTA 1.5 network upgrade.', + stardust: 'The name of the first Shimmer network upgrade.', + data: 'The tangle is a way of proving the integrity of data (verifiability of completeness and origin) in a trustworthy manner. At present, there are several cryptographic methods that make this possible, but security gaps are repeatedly discovered here, making data vulnerable to manipulation. This is a major problem, especially in cloud computing, where third-party audit tools are sometimes even used (for a fee) to ensure this data integrity. This is exactly where IOTA and Shimmer come in and offers a relatively easy way to escape this with its protocol and without fees.', + 'data transactions': + 'These are confirmed directly and are notarized. With the help of "notarization", it can be proven that an electronic document existed in a certain form at a certain time and has not been changed since its creation. When a notarization is created, a unique hash (fingerprint) of a document is calculated and stored together with a timestamp in the ledger (Tangle) in an immutable manner.', + 'data storage': + 'Just like the internet, the IOTA and Shimmer protocols do not store data or in other words, the Tangle is not a data storage. If someone wants to store the history of transactions in a decentralized way, they can build a second-layer solution for this themselves or pay third parties for this storage. For the basic layer, IOTA and Shimmer focus on performance, throughput, and security rather than building a global database.', + 'distributed ledger technology (dlt)': + 'This is a database architecture that allows owners of digital assets to transfer and document them from peer to peer. Each transfer in a DLT is stored as a record in a distributed ledger (database). This database is stored in all nodes of a network.', + devnet: + 'The DevNet (developer network) is a pure test network to research and test a Tangle without Coordinator.', + decay: + 'Both Mana and pending Mana decay proportionally to its value, preventing Mana from growing indefinitely over time.', + 'double-spending': + 'Double-spending is a threat to a digital money system, where the same single digital token can be spent more than once. Unlike physical money, a digital token consists of a digital file that can be duplicated or counterfeited.', + 'drng (decentralized random number generator)': + 'This random number generator is required in Fast Probabilistic Consensus (FPC) to make the consensus model more resilient to attacks. In the case of conflicting transactions, the FPC votes on the transactions in question in several rounds. The threshold at which a node changes its mind in this vote is 50% +/- a small random deviation (using dRNG). In order to avoid stalemate or a specific outcome in the voting, this additional random component prevents potentially malicious nodes from influencing the voting process.', + 'dust protection (iota 1.5)': + 'Someone who wants to harm IOTA could automatically send 1i for years to repeatedly recreated addresses, driving up the ledger\u2019s memory requirements to the point where a full-node would eventually only run on large servers. In Chrysalis if you want to create a microtransaction (<1Mi) you need to activate dust on the receiving address. That will allow you to receive a certain amount of dust. Also, the addresses with Colored Coins have to be tokenized. After the Coordicide, there will be another solution for IOTA 2.0.', + 'directed acyclic graph (dag)': + 'A directed acyclic graph is DLT structure that consists of edges and vertices that never form a closed loop. The Tangle is a form of directed acyclic graph.', + 'eclipse attack': + 'A cyber-attack that aims to isolate a specific node rather than attack the entire network.', + 'eth virtual machine': + 'A VM is what executes the Smart Contract code so that it runs deterministically. The language in which you run the code provides hooks to access the sandbox on which the VM runs. In the case of Shimmer, this is the ISC sandbox, which only provides access to Shimmer tokens, thus consensus also runs on Shimmer tokens. It is only the VM that Shimmer works with, foreign tokens have nothing to do with a VM running the SC code, not the ETH VM, nor the Cartesi VM.', + 'epoch (iota 2.0)': + 'A time interval used for a specific type of consensus mana. At the end of each epoch, a snapshot is taken of the state of mana distribution on the network. Since this tool uses the timestamp of messages, each node can eventually reach a consensus on the mana distribution of an epoch.', + faucet: + 'A pool of tokens (funds). Upon uncomplicated request, one gets a limited number of tokens for testing, especially for developers of own apps this is a great help.', + firefly: + 'Firefly is a wallet, intended to serve as a platform for the current and future IOTA and Shimmer ecosystem.', + finality: + 'The property that once a transaction has been completed, there is no way to reverse or change it. This is the moment when the parties involved in a transfer can consider the transaction completed. Finality can be deterministic or probabilistic.', + 'full nodes (hornet, bee)': + 'They form the core (infrastructure) of the network. In order to participate in the peer-to-peer network, the full node must always be online and connected to neighbors (other full nodes). In addition, the transaction database must be synchronized with all other full nodes in the network. The role of full nodes is to interact with clients (wallets, DApps, etc.) and attach their transactions to the ledger, make transactions known to all other full nodes in the network, validate transactions and store them in the ledger.', + 'future cone': + 'All messages that directly or indirectly reference a message are called its future cone.', + fork: 'In IT, this is a new development branch after a project is split into a second follow-on project; the source code or parts of it are developed independently of the original parent project.', + 'fpc(fast probabilistic consensus)': + 'Consensus that uses a random number and node opinions to reach consensus. In On-Tangle Voting, it is only used in a specific edge case. Check out OTVFPCS.', + 'genesis transaction': + 'The Genesis transaction is the first transaction that created all IOTA and Shimmer tokens and distributed them to the addresses of the buyers.', + 'goshimmer (no main net)': + 'Prototype of the coordinator less version of IOTA written in the Go programming language. GoShimmer implements the various modules of Coordicide, such as auto peering, node identities, Mana, etc. GoShimmer serves as a test environment for the first alpha version and the test network. Everything tested here will be gradually merged with Hornet and Bee.', + 'generic data object (iota 2.0)': + 'The most basic object type. All unrecognized data objects are defined this way.', + history: + 'The list of transactions that were directly or indirectly authorized by a particular transaction.', + 'hash values': + 'Checksums that are applied to the encryption of messages of variable length. Hash values are like fingerprints of a very long data set. Each message is assigned a very specific hash value.', + hooks: + 'An interface that allows foreign program code to be integrated into an existing application to extend it, change its flow, or intercept certain events.', + 'hornet node (iota 1.5)': + 'Community-developed IOTA Node written in the Go programming language. In addition, the coordinator also runs as a plugin via Hornet.', + 'hornet node (shimmer)': + 'Shimmer Node written in the Go programming language. In addition, the coordinator also runs as a plugin via Hornet.', + 'inclusion state': + 'Used to determine if a transaction has been accepted and confirmed by the network. Especially for a transaction and a list of tips: Inclusion state is true if the tip refers to this transaction.', + 'local snapshots': + 'Local snapshots are used to limit the memory requirements of the nodes. For this purpose, on the individual nodes old, already confirmed, transactions are deleted from the database. What remains is only a small file (list) with the balances on the respective addresses. Nodes perform the snapshot independently and at their own discretion. This feature allows faster synchronization, lower system resource requirements and no more waiting for global snapshots to clean up the database.', + layer: + 'In DLT a 2nd-layer refers to a secondary framework or protocol built on top of an existing distributed ledger. On these second layers, other applications can be executed without putting too much strain on the base layer. For example, Smart Contracts.', + 'local modifiers': + 'User-defined conditions that can be considered by nodes during tip selection. In IOTA and Shimmer, nodes do not necessarily have the same view of the tangle. Different types of information that are only available to them locally can be used to strengthen security.', + 'merkle tree': + 'A Merkle tree is a data structure used in computer science applications. In cryptocurrencies, Merkle trees are used to encode more efficiently and securely.', + mainnet: + 'The public usable IOTA network, in which the IOTA tokens are used that are traded on cryptocurrency exchanges.', + 'milestone (iota 1.5)': + 'Milestones are messages that are signed and issued by the coordinator. Their main goal is to help the Tangle grow healthily and guarantee finality. When milestones directly or indirectly approve a transaction in the Tangle, nodes mark the status of that transaction and its entire history as confirmed.', + message: + 'A message is a core data type that reflects a vertex in the communication layer DAG. It contains the following properties: References to other messages, the sender\u2019s public key, the issuing time of the message, the message sequence number from the node that issued the message, the payload that can be interpreted by higher layers, the nonce that the message uses to satisfy the PoW requirement, a signature that signs all of the above fields. A message is not forwarded until it becomes "solid", i.e., its history is known to the node. Messages must meet a PoW requirement, which currently is to find a nonce so that the hash of the message\u2019s fields (minus the signature) has a certain number of leading zeros.', + 'message overhead': + 'The additional information (metadata) that must be sent along with the actual information (data). This can include signatures, polls and anything that is transmitted over the network but is not the transaction itself.', + 'mana (iota 2.0)': + 'When a value transaction is processed, a quantity called Mana will be "pledged" to a specified node ID. This quantity is related to the amount of IOTA moved into the transaction. The only way to gain Mana is to convince some token holder to pledge it to you. In this sense, Mana is Delegated Proof of Token Ownership. Mana, therefore, provides adequate Sybil protection because it is difficult to acquire it in arbitrary amounts.', + 'markers (iota 2.0)': + 'A tool that exists only locally and allows certain calculations to be performed more efficiently, such as the calculation of the approval weight or the presence of certain messages in the past or future cone of another message.', + 'messages per second (mps)': + 'The amount of messages issued to the network every second.', + 'nakamoto consensus': + 'Named after the creator of Bitcoin, Satoshi Nakamoto, the Nakamoto Consensus describes the replacement of coordination / communication between known agents with a cryptographic puzzle (Proof-of-Work). Completion of the puzzle determines which agent acts next.', + neighbors: + 'Network nodes that are directly connected and can exchange messages without intermediate nodes.', + nodes: + 'A node is any computer that connects to other nodes in the network via software. In principle, they serve as a connection point for data transfers. The Tangle works with different types of nodes, such as full nodes (Hornet, Bee), permanodes (Chronicle) or smart contract nodes (Wasp).', + 'network layer (iota 2.0)': + 'This layer manages the lower layers of Internet communication such as TCP. In this layer, the connections between the nodes are managed by the Auto peering and Peer Discovery modules and the Gossip protocol.', + 'network id': + 'The network ID enables user-specific subtangles in which nodes can only recognize messages from the network ID listed in their configuration file.', + orphan: + 'A transaction (or block) that is not referenced by any subsequent transaction (or block). An orphan is not considered confirmed and will not be part of the consensus.', + 'object (iota 2.0)': + 'the most basic unit of information in the IOTA protocol. Each object has a type and size and contains data.', + oracles: + 'Oracles are designed to build a secure bridge between the digital and physical worlds in a decentralized, permissionless way. They bring off-chain data to decentralized applications and smart contracts on the network.', + 'otv (iota 2.0)': + 'On Tangle Voting is the official name for the multiverse consensus described by Hans Moog. It is a new consensus mechanism that allows nodes to vote on conflicts directly by publishing a message to the tangle.', + 'otvfpcs (iota 2.0)': + 'On Tangle Voting with FPCS (Fast Probabilistic Consensus on a Set) is a mechanism for breaking metastability, which can be used in addition to OTV (On Tangle Voting). Generally, in IOTA2.0, reaching a high approval weight is the finality criteria. If the approval weight is high enough, the message / transaction is finalized. With OTVFPC the initial opinion is created with OTV, if after some time the opinions of the nodes are still split, for whatever reason, FPC is activated to break this metastable state. The finality of value transactions should be reached faster this way.', + parents: + 'A message directly references up to 8 previous messages that we call its parents. In IOTA 2.0 a parent can be either strong or weak (see approval switch).', + 'parallel reality ledger state (iota 2.0)': + 'This state is used to track conflicts in the tangle. Two new ledger entries that are causally valid but in conflict with each other (ex. Double Spend) are posted into two separate "realities" for this purpose, representing possible but mutually exclusive future ledger states. The consensus mechanism (with FPC, etc.) will now operate until the perception of most nodes tilts in one direction and one of the two possible ledger states is accepted as true.', + 'partition tolerant': + 'This means that a part of the Tangle can be disconnected from the main tangle for a certain time and continue to run without an Internet connection. These parts can be reconnected to the main Tangle when the Internet connection is restored.', + 'past cone': + 'All messages that are directly or indirectly referenced by a message are called its past cone.', + 'parasite chain attacks': + 'A double spending attack on the Tangle. Here, an attacker attempts to reverse a transaction by setting up an alternate Tangle in which the funds were not spent. He then tries to get the majority of the network to accept the alternative Tangle as the legitimate one.', + permanode: + 'This type of node permanently stores the entire transaction history, possibly with the help of external storage solutions, and possibly only specific transactions (selective permanode).', + pending: 'A transaction has been seen by the network but not yet confirmed.', + 'peer to peer network': + 'A decentralized network of different network nodes that are connected to each other and exchange data.', + peering: 'The process of discovering and connecting to other network nodes.', + 'payload (iota 2.0)': + 'A field in a message that determines the type. Examples are value payload (TransactionType type), FPC opinion payload (StatementType type), dRNG payload (Payload), Salt declaration payload, generic data payload.', + 'private tangle': + 'A private tangle is comparable to a test network under complete control of the operator. This allows companies and developers to test their applications under self-defined environment variables without external influences and protected from prying eyes. There is no interoperability between a private Tangle and the IOTA or Shimmer Tangle. So, sending from one to the other does not work either. Each private Tangle is an independent network with its own nodes, tokens, and coordinator.', + 'proof of work (pow)': + 'A time-consuming (expensive) mathematical calculation that uses computational power to prevent spam attacks. It consists of a difficult cryptographic puzzle that is easy to verify.', + 'proof of inclusion (poi)': + 'With PoI, one is able to provide evidence that a transaction was indirectly referenced by another transaction without having to present the full chain of actual transactions between the two transactions. This is done by using a sequence of hashes instead of the actual transaction data to prove the inclusion of a transaction (inclusion) in the referenced subtangle.', + pruning: + 'In computer science, this is a term for simplifying, shortening, and optimizing decision trees. In Shimmer, this is done by local snapshots on each full node. Old transactions that have already been confirmed are deleted from the database, leaving only a file (list) of credits on each address.', + 'public and private keys': + 'These are used in cryptographic systems which use key pairs. There are public keys which can be shared and private keys which are known only to the owner. The generation of such keys depends on cryptographic algorithms based on mathematical problems to generate one-way functions. Effective security requires keeping the private key to remain only known to the owner. Public keys derived from this private key can be shared and used by others to verify ownership of the private key, without exposing the private key. Public keys function as addresses in IOTA and Shimmer.', + rebroadcast: + 'Repeats the sending of a transaction. While a transaction is being sent to a node, it may go offline. In this case, the node may not forward the transactions to its neighbors, and the rest of the network will never see these transactions. As a result, that transaction will never be referenced by the coordinator and thus never confirmed. Resending a bundle means resending the same bundle to a node. This way you give your transactions another chance to be forwarded to the rest of the network.', + 'reusable addresses': + 'With the introduction of the Ed25519 signature scheme, through the IOTA 1.5 Chrysalis upgrade, reusable addresses are now supported.', + reattachment: + 'Resending a transaction by re-selecting a tip and referencing newer tips by repeating PoW.', + salt: 'In cryptography, salt is a randomly chosen string of characters that is appended to a given plaintext before it is further processed to increase the entropy (disorder) of the input. It is often used for storing and transmitting passwords to increase information security.', + sandbox: 'An isolated area where programs can be tested.', + 'software as a service (saas)': + 'The SaaS model is a subset of cloud computing. It is based on the principle that the software and IT infrastructure can be operated by an external service provider and rented by the customer as a service.', + 'smart contract': + 'Smart contracts are contracts or programs that are automatically executed.', + 'smart contract chain': + 'Smart contracts are processed via a so-called contract chain, the representation of the contract state. A smart contract writes its state every time it is requested, and a new block is added for each of these state updates. All these updates are collected and confirmed in one block. So, the chain also contains all the past states. The chain can contain many Smart Contracts, all working on the same global state of the chain. From this perspective, the Contract chain is essentially a blockchain anchored on the Tangle. IOTA Smart Contracts can be considered "classic" Smart Contracts, but with the added feature that you can have multiple such parallel chains all using the same native IOTA and Shimmer tokens, and trading between them in a trusted manner on the Tangle. This enables trusted interoperability between different applications.', + 'solidification time': + 'The time of solidification when the entire history of a transaction has been received by a node.', + 'splitting attacks': + 'An attack in which a malicious node attempts to split the tangle into two branches. As one of the branches grows, the attacker publishes transactions on the other branch to keep both alive. Splitting attacks attempt to slow down the consensus process or perform double spending.', + sharding: + 'Nodes have an upper limit on transactions per second (TPS) they can process. Through a type of database partitioning (breaking a very large database into smaller ones) into more manageable segments (shards), each shard would contain a unique set of account balances and nodes would then be assigned to individual shards to validate transactions. The goal is that by dividing into more manageable segments, it will increase transaction throughput and thus overcome scalability issues.', + signatures: + 'Signatures prove ownership of an address. Clients (Wallets) need this proof before nodes validate a transaction. To prove ownership, input transactions must be signed with the private key used to create the address.', + 'solidity (iota 2.0)': + 'A message is marked as solid if its entire past cone until the Genesis (or the latest snapshot) is known.', + subtangle: + 'A consistent section of the tangle (i.e., a subset of messages / value objects) such that each contained message / value object also contains its referenced messages / value objects.', + streams: + 'IOTA Streams is a multifunctional second layer data transfer protocol that can be used for various types of data transfer (e.g., streaming data). For example, it allows sensors and other devices to encrypt entire data streams and anchor them in the IOTA Tangle. IOTA\u2019s consensus protocol adds integrity and authenticity to these message streams. Given these characteristics, IOTA Streams fills an important need in industries where integrity, privacy, and immutability collide.', + 'sybil attack': + 'An attempt to gain control of a peer-to-peer network by forging multiple false identities.', + snapshot: + 'A special feature of the Tangle. A snapshot deletes all transactions. Only transactions with a balance > 0 are kept. The metadata such as tags and messages are also deleted. What is left behind is just a list of addresses and balances. After a snapshot, the nodes use this list as "genesis", a new starting point for the tangle. This reduces the size of the tangle network, allowing nodes to use less memory. Full nodes perform what are called "Local Snapshots" independently and at their own discretion.', + tangle: + 'The Tangle is the underlying core data structure. In mathematical terms it is a directed acyclic graph (DAG). The Tangle is the distributed ledger that stores all transactions.', + 'ternary system': + 'A trit (trinary digit) can have exactly three states (3 x 1 = 3): -1, 0 and 1. Three trits result in one tryte (33 = 27) and can thus represent 27 combinations. In IOTA, the letters A-Z (26 pieces) and the number 9 are used for this purpose.', + token: + 'The digital currency form (cryptocurrency). It is a powerful tool for value transfer between people and machines. Total number: 2,779,530,283,277,761 IOTA. The base units are Pi, Ti, Gi, Mi, ki, i', + 'trinity (iota 1.0)': 'Depreciated IOTA Wallet', + tip: 'A transaction that has not yet been approved.', + 'tip selection': + 'The process of selecting previous transactions to be referenced by a new transaction. In these references, a transaction ties into the existing data structure. IOTA and Shimmer only enforces that a transaction approves up to eight other transactions, the tip selection strategy is left to the user (with a good default provided by Shimmer).', + 'tip transaction': 'A solid end transaction that is not yet a parent.', + 'transaction (iota 2.0)': + 'A message that contains a Token transfer as a payload. The transferred tokens can be native IOTA Tokens or native IOTA Assets.', + 'utxo model': + 'This is a so-called addressing model. UTXO stands for "unspent transaction output", which simply means that you not only keep track of the credits on the address, but also keep track of where the credits come from and where they are sent when they are spent. Each token on an address is thus uniquely identifiable and each issue names the exact token they want to move. This enables faster and more accurate conflict handling and improves the resilience and security of the protocol.', + 'value layer (iota 2.0)': + 'The Value layer builds on the Communication layer. It works exclusively with payloads of type Value object. This layer has several tasks: Forming the ledger state, processing, validation and output of transactions, conflict detection, conflict resolution via FPC, forming a DAG from value objects, tip selection (on value object tips).', + 'value transactions': + 'Value transactions either withdraw tokens from an address or deposit them to an address. Nodes must verify these transactions to ensure that the sender actually owns the Shimmer tokens and that additional tokens are never generated. To do this, the following checks are performed: All Shimmer tokens withdrawn from an address are also deposited into one or more other addresses; the value of each transaction does not exceed the total global supply; signatures are valid.', + 'version number (iota 2.0)': 'Indicates the correct format of each type.', + 'white-flag approach (iota 1.5)': + 'Used to calculate credits. A simpler, conflict-avoiding approach that improves the speed and efficiency of tip selection, eliminates certain attacks, and significantly reduces the need for reattachments.', + wasp: 'The Wasp node software is an implementation of Smart Contracts on the Tangle.', +}; diff --git a/package.json b/package.json index 149239ad318..200923f845a 100644 --- a/package.json +++ b/package.json @@ -7,6 +7,7 @@ "start:next": "(ENVIRONMENT=next; yarn generate:api && yarn start)", "start:all": "yarn build:all && yarn serve", "build:plugins": "yarn ./plugins/tutorial build", + "build:theme": "yarn ./theme build", "build:iota": "(ENVIRONMENT=iota; yarn generate:api && yarn build --out-dir build)", "build:shimmer": "(ENVIRONMENT=shimmer; yarn generate:api && yarn build --out-dir build/shimmer)", "build:next": "(ENVIRONMENT=next; yarn generate:api && yarn build --out-dir build/next)", diff --git a/shimmer/jargon.js b/shimmer/jargon.js deleted file mode 100644 index e2570dcaa70..00000000000 --- a/shimmer/jargon.js +++ /dev/null @@ -1,7 +0,0 @@ -module.exports = { - rehype: - 'rehype is a tool that transforms HTML with plugins. These plugins can inspect and change the HTML. You can use rehype on the server, the client, CLIs, deno, etc.', - freesewing: - 'FreeSewing is an open source platform for made-to-measure sewing patterns. See freesewing.org', - iota: 'Test', -}; diff --git a/shimmer/learn/glossary.md b/shimmer/learn/glossary.md deleted file mode 100644 index 0a4edbdf10b..00000000000 --- a/shimmer/learn/glossary.md +++ /dev/null @@ -1,187 +0,0 @@ ---- -title: Glossary -description: Glossary of all specialized names and phrases used in the Shimmer Technology. If you dont understand a wording you will find answers here. ---- - -# Glossary - -## A - -- **Address Checksum:** Checksum validation is a way to determine if an address is valid and does not contain typos. -- **Dynamic PoW** (In development for Shimmer): With this feature, the coordinator can issue a milestone and simultaneously set the future PoW score. This means that if the network is not fully utilized, the PoW will be reduced to the point where it can be executed by microdevices. Accordingly, the coordinator can also raise the PoW difficulty in case of high utilization and thus make an attack very expensive. -- **Auto peering:** A mechanism that allows nodes to automatically select their neighbors without manual intervention by the node operator. -- **API(Application Programming Interfaces):** The way for applications to interact with the Tangle. -- **Atomic Transactions:** Instead of the bundle construct, Shimmer uses simpler Atomic Transactions. An Atomic Transaction includes everything related to a transaction in a single message instead of splitting it up (Bundles). This reduces network overhead and signature verification load, improves spam protection and rate control, and shortens the length of Merkle proofs (for future sharding). It also reduces implementation overhead and increases maintainability of the core node software. -- **Application Layer (IOTA 2.0):** The top layer of the 3-layer communication protocol. The IOTA protocol allows a variety of external applications to run on the Message Tangle. Anyone can design an application and users can decide which applications to run on their nodes. These applications will all use the communication layer to transmit and store data. -- **Approval Switch (IOTA 2.0):** When a message is selected as a parent, we can choose from the strong or weak tip pool. This mechanism is called Approval Switch. -- **Approval Weight (IOTA 2.0):** A message gets Mana-weight by approving the message directly or indirectly. However, only strong parents can pass on the mana weight to the past, while weak parents receive the weight from their weak children but do not pass it on. -- **Approvers (IOTA 2.0):** Parents are approved by their referencing messages called approvers. It is thus a reverse mapping of parents. As in the parents’ definition, an approver might be either strong or weak. - -## B - -- **Balance:** Funds on the addresses (account). These are always available and cannot be deleted or forgotten. -- **Blockchain Bottleneck:** The more transactions are issued, the more the block rate and size become a bottleneck in the system. It is no longer possible to capture all incoming transactions in a prompt manner. Attempts to speed up block rates result in more orphaned blocks (blocks are left behind) and reduce the security of the blockchain. -- **Branch (IOTA 2.0):** A version of the ledger that temporarily coexists with other versions, each spawned by conflicting transactions. -- **Bootstrapping attack:** An attack in which a node downloads malicious snapshot files, including invalid transactions and balances. - -## C - -- **Curl:** This is one of the hash functions currently in use. It is based on the “sponge” construction of the Keccak inventors (SHA-3). -- **Confirmed:** Confirmed transactions. In Shimmer, messages in the Tangle are considered for confirmation only when they are directly or indirectly referenced by a milestone that the Coordinator node has validated. To allow the nodes to recognize the milestones, all nodes that participate in the same Shimmer network are configured with the Merkle root address of a Coordinator that they trust to confirm messages. Using this address, nodes can validate the signatures in milestones to verify whether the trusted Coordinator signs them. To make sure that new messages always have a chance of being confirmed, the Coordinator sends indexed milestones at regular intervals. This way, nodes can compare the indexes of their milestones to check whether they are synchronized with the rest of the network. -- **CTPS:** Confirmed transactions per second. -- **Cumulative Weight:** A system for valuing transactions. Each additional transaction that references a transaction increases its cumulative weight. When tips are selected, a path through transactions that has a higher cumulative weight is preferred. -- **Chronicle:** A permanode solution of the IOTA Foundation. It allows to store all transactions reaching a node in a distributed database that is secure and scales well. Chronicle is used to store the Tangle’s unlimited data flow and make it queryable. In other words, permanence allows the entire history of the Tangle to be stored indefinitely and makes that data easily accessible. -- **Consensus:** Agreement on a specific date or value in distributed multi-agent systems, in the presence of faulty processes. -- **Coordinator (only up to IOTA 2.0):** A trusted entity, as protection against malicious transactions. The Tangle is not yet a final product, it is still in beta. The network currently relies on a kind of shield, the so-called coordinator. It is open-source and runs on a Hornet node. The COO acts as a centralized, voluntary, and temporary alternative consensus mechanism for the Tangle. To do this, the COO sends honest transactions to the full nodes at regular intervals. These packets contain a signed message with no value, called a milestone. The full nodes in the Tangle consider a transaction as confirmed only if it is approved by a milestone. Important: The coordinator can only confirm transactions, but he cannot bypass the consensus rules. To create, freeze or steal tokens is not possible for him. This fixed rule and the COO address is hardcoded on each full node, so the coordinator’s influence on the tangle is very limited, since the tangle is also constantly monitored by all the other full nodes. > The Coo will be switched off with the IOTA 2.0 upgrade. -- **Communication Layer (IOTA 2.0):** This layer stores and communicates information. This layer contains the distributed ledger or tangle. The rate control and timestamps are also located in this layer. -- **Core Object type (IOTA 2.0):** An object type that must be parsed by all nodes. Parsers are computer programs responsible for decomposing and converting an input into a format more suitable for further processing. -- **Core Application (IOTA 2.0):** Core application that must be executed by all nodes, for example the value transfer application. -- **Child (IOTA 2.0):** A transaction that gets referenced by Parents. -- **Chrysalis:** The name of the IOTA 1.5 network upgrade. -- **Stardust:** The name of the first Shimmer network upgrade. - -## D - -- **Data:** The tangle is a way of proving the integrity of data (verifiability of completeness and origin) in a trustworthy manner. At present, there are several cryptographic methods that make this possible, but security gaps are repeatedly discovered here, making data vulnerable to manipulation. This is a major problem, especially in cloud computing, where third-party audit tools are sometimes even used (for a fee) to ensure this data integrity. This is exactly where Shimmer comes in and offers a relatively easy way to escape this with its protocol and without fees. -- **Data transactions:** These are confirmed directly and are notarized. With the help of “notarization”, it can be proven that an electronic document existed in a certain form at a certain time and has not been changed since its creation. When a notarization is created, a unique hash (fingerprint) of a document is calculated and stored together with a timestamp in the Shimmer ledger (tangle) in an immutable manner. -- **Data storage:** Just like the internet, the Shimmer protocol does not store data or in other words, the Tangle is not a data storage. If someone wants to store the history of transactions in a decentralized way, they can build a second-layer solution for this themselves or pay third parties for this storage. For the basic layer, Shimmer focuses on performance, throughput, and security rather than building a global database. -- **Distributed Ledger Technology (DLT):** This is a database architecture that allows owners of digital assets to transfer and document them from peer to peer. Each transfer in a DLT is stored as a record in a distributed ledger (database). This database is stored in all nodes of a network. -- **DevNet:** The DevNet (developer network) is a pure test network to research and test a Tangle without Coordinator. -- **Decay:** Both Mana and pending Mana decay proportionally to its value, preventing Mana from growing indefinitely over time. -- **Double-spending:** Double-spending is a threat to a digital money system, where the same single digital token can be spent more than once. Unlike physical money, a digital token consists of a digital file that can be duplicated or counterfeited. -- **dRNG (Decentralized Random Number Generator):** This random number generator is required in Fast Probabilistic Consensus (FPC) to make the consensus model more resilient to attacks. In the case of conflicting transactions, the FPC votes on the transactions in question in several rounds. The threshold at which a node changes its mind in this vote is 50% +/- a small random deviation (using dRNG). In order to avoid stalemate or a specific outcome in the voting, this additional random component prevents potentially malicious nodes from influencing the voting process. -- **Dust Protection (IOTA 1.5):** Someone who wants to harm IOTA could automatically send 1i for years to repeatedly recreated addresses, driving up the ledger’s memory requirements to the point where a full-node would eventually only run on large servers. In Chrysalis if you want to create a microtransaction (<1Mi) you need to activate dust on the receiving address. That will allow you to receive a certain amount of dust. Also, the addresses with Colored Coins have to be tokenized. After the Coordicide, there will be another solution for IOTA 2.0. -- **Directed Acyclic Graph (DAG):** A directed acyclic graph is DLT structure that consists of edges and vertices that never form a closed loop. The Shimmer architecture "the Tangle" is a form of directed acyclic graph. - -## E - -- **Eclipse attack:** A cyber-attack that aims to isolate a specific node rather than attack the entire network. -- **ETH Virtual Machine:** A VM is what executes the Smart Contract code so that it runs deterministically. The language in which you run the code provides hooks to access the sandbox on which the VM runs. In the case of Shimmer, this is the ISC sandbox, which only provides access to Shimmer tokens, thus consensus also runs on Shimmer tokens. It is only the VM that Shimmer works with, foreign tokens have nothing to do with a VM running the SC code, not the ETH VM, nor the Cartesi VM. -- **Epoch (IOTA 2.0):** A time interval used for a specific type of consensus mana. At the end of each epoch, a snapshot is taken of the state of mana distribution on the network. Since this tool uses the timestamp of messages, each node can eventually reach a consensus on the mana distribution of an epoch. - -## F - -- **Faucet:** A pool of tokens (funds). Upon uncomplicated request, one gets a limited number of tokens for testing, especially for developers of own apps this is a great help. -- **Firefly:** Firefly is a wallet, intended to serve as a platform for the current and future Shimmer ecosystem. -- **Finality:** The property that once a transaction has been completed, there is no way to reverse or change it. This is the moment when the parties involved in a transfer can consider the transaction completed. Finality can be deterministic or probabilistic. -- **Full nodes (Hornet):** They form the core (infrastructure) of the Shimmer network. In order to participate in the peer-to-peer network, the full node must always be online and connected to neighbors (other full nodes). In addition, the transaction database must be synchronized with all other full nodes in the network. The role of full nodes is to interact with clients (wallets, DApps, etc.) and attach their transactions to the ledger, make transactions known to all other full nodes in the network, validate transactions and store them in the ledger. -- **Future Cone:** All messages that directly or indirectly reference a message are called its future cone. -- **Fork:** In IT, this is a new development branch after a project is split into a second follow-on project; the source code or parts of it are developed independently of the original parent project. -- **FPC(Fast Probabilistic Consensus):** Consensus that uses a random number and node opinions to reach consensus. In On-Tangle Voting, it is only used in a specific edge case. Check out OTVFPCS. - -## G - -- **Genesis transaction:** The Genesis transaction is the first transaction that created all Shimmer tokens and distributed them to the addresses of the buyers. -- **GoShimmer (No Main net):** Prototype of the coordinator less version of IOTA written in the Go programming language. GoShimmer implements the various modules of Coordicide, such as auto peering, node identities, Mana, etc. GoShimmer serves as a test environment for the first alpha version and the test network. Everything tested here will be gradually merged with Hornet. -- **Generic Data Object (IOTA 2.0):** The most basic object type. All unrecognized data objects are defined this way. - -## H - -- **History:** The list of transactions that were directly or indirectly authorized by a particular transaction. -- **Hash values:** Checksums that are applied to the encryption of messages of variable length. Hash values are like fingerprints of a very long data set. Each message is assigned a very specific hash value. -- **Hooks:** An interface that allows foreign program code to be integrated into an existing application to extend it, change its flow, or intercept certain events. -- **Hornet Node:** Shimmer Node written in the Go programming language. In addition, the coordinator also runs as a plugin via Hornet. - -## I - -- **Inclusion state:** Used to determine if a transaction has been accepted and confirmed by the network. Especially for a transaction and a list of tips: Inclusion state is true if the tip refers to this transaction. - -## L - -- **Local Snapshots:** Local snapshots are used to limit the memory requirements of the nodes. For this purpose, on the individual nodes old, already confirmed, transactions are deleted from the database. What remains is only a small file (list) with the balances on the respective addresses. Nodes perform the snapshot independently and at their own discretion. This feature allows faster synchronization, lower system resource requirements and no more waiting for global snapshots to clean up the database. -- **Layer:** In DLT a 2nd-layer refers to a secondary framework or protocol built on top of an existing distributed ledger. On these second layers, other applications can be executed without putting too much strain on the base layer. In Shimmer, for example, these are the Smart Contracts. -- **Local Modifiers:** User-defined conditions that can be considered by nodes during tip selection. In Shimmer, nodes do not necessarily have the same view of the tangle. Different types of information that are only available to them locally can be used to strengthen security. - -## M - -- **Merkle Tree:** A Merkle tree is a data structure used in computer science applications. In cryptocurrencies, Merkle trees are used to encode more efficiently and securely. -- **Mainnet:** The public usable IOTA network, in which the IOTA tokens are used that are traded on cryptocurrency exchanges. -- **Milestone (IOTA 1.5):** Milestones are messages that are signed and issued by the coordinator. Their main goal is to help the Tangle grow healthily and guarantee finality. When milestones directly or indirectly approve a transaction in the Tangle, nodes mark the status of that transaction and its entire history as confirmed. -- **Message:** A message is a core data type that reflects a vertex in the communication layer DAG. It contains the following properties: References to other messages, the sender’s public key, the issuing time of the message, the message sequence number from the node that issued the message, the payload that can be interpreted by higher layers, the nonce that the message uses to satisfy the PoW requirement, a signature that signs all of the above fields. A message is not forwarded until it becomes “solid”, i.e., its history is known to the node. Messages must meet a PoW requirement, which currently is to find a nonce so that the hash of the message’s fields (minus the signature) has a certain number of leading zeros. -- **Message overhead:** The additional information (metadata) that must be sent along with the actual information (data). This can include signatures, polls and anything that is transmitted over the network but is not the transaction itself. -- **Mana (IOTA 2.0):** When a value transaction is processed, a quantity called Mana will be “pledged” to a specified node ID. This quantity is related to the amount of IOTA moved into the transaction. The only way to gain Mana is to convince some token holder to pledge it to you. In this sense, Mana is Delegated Proof of Token Ownership. Mana, therefore, provides adequate Sybil protection because it is difficult to acquire it in arbitrary amounts. -- **Markers (IOTA 2.0):** A tool that exists only locally and allows certain calculations to be performed more efficiently, such as the calculation of the approval weight or the presence of certain messages in the past or future cone of another message. -- **Messages per Second (MPS):** The amount of messages issued to the network every second. - -## N - -- **Nakamoto Consensus:** Named after the creator of Bitcoin, Satoshi Nakamoto, the Nakamoto Consensus describes the replacement of coordination / communication between known agents with a cryptographic puzzle (Proof-of-Work). Completion of the puzzle determines which agent acts next. -- **Neighbors:** Network nodes that are directly connected and can exchange messages without intermediate nodes. -- **Nodes:** A node is any computer that connects to other nodes in the network via software. In principle, they serve as a connection point for data transfers. The Tangle works with different types of nodes, such as full nodes like Hornet, permanodes (Chronicle) or smart contract nodes (Wasp). -- **Network Layer (IOTA 2.0):** This layer manages the lower layers of Internet communication such as TCP. In this layer, the connections between the nodes are managed by the Auto peering and Peer Discovery modules and the Gossip protocol. -- **Network ID:** The network ID enables user-specific subtangles in which nodes can only recognize messages from the network ID listed in their configuration file. - -## O - -- **Orphan:** A transaction (or block) that is not referenced by any subsequent transaction (or block). An orphan is not considered confirmed and will not be part of the consensus. -- **Object (IOTA 2.0):** the most basic unit of information in the IOTA protocol. Each object has a type and size and contains data. -- **Oracles:** Oracles are designed to build a secure bridge between the digital and physical worlds in a decentralized, permissionless way. They bring off-chain data to decentralized applications and smart contracts on the Shimmer network. -- **OTV (IOTA 2.0):** On Tangle Voting is the official name for the multiverse consensus described by Hans Moog. It is a new consensus mechanism that allows nodes to vote on conflicts directly by publishing a message to the tangle. -- **OTVFPCS (IOTA 2.0):** On Tangle Voting with FPCS (Fast Probabilistic Consensus on a Set) is a mechanism for breaking metastability, which can be used in addition to OTV (On Tangle Voting). Generally, in IOTA2.0, reaching a high approval weight is the finality criteria. If the approval weight is high enough, the message / transaction is finalized. With OTVFPC the initial opinion is created with OTV, if after some time the opinions of the nodes are still split, for whatever reason, FPC is activated to break this metastable state. The finality of value transactions should be reached faster this way. - -## P - -- **Parents:** A message directly references up to 8 previous messages that we call its parents. In IOTA 2.0 a parent can be either strong or weak (see approval switch). -- **Parallel reality ledger state (IOTA 2.0):** This state is used to track conflicts in the tangle. Two new ledger entries that are causally valid but in conflict with each other (ex. Double Spend) are posted into two separate “realities” for this purpose, representing possible but mutually exclusive future ledger states. The consensus mechanism (with FPC, etc.) will now operate until the perception of most nodes tilts in one direction and one of the two possible ledger states is accepted as true. -- **Partition Tolerant:** This means that a part of the Tangle can be disconnected from the main tangle for a certain time and continue to run without an Internet connection. These parts can be reconnected to the main Tangle when the Internet connection is restored. -- **Past Cone:** All messages that are directly or indirectly referenced by a message are called its past cone. -- **Parasite Chain Attacks:** A double spending attack on the Tangle. Here, an attacker attempts to reverse a transaction by setting up an alternate Tangle in which the funds were not spent. He then tries to get the majority of the network to accept the alternative Tangle as the legitimate one. -- **Permanode:** This type of node permanently stores the entire transaction history, possibly with the help of external storage solutions, and possibly only specific transactions (selective permanode). -- **Pending:** A transaction has been seen by the network but not yet confirmed. -- **Peer to Peer Network:** A decentralized network of different network nodes that are connected to each other and exchange data. -- **Peering:** The process of discovering and connecting to other network nodes. -- **Payload (IOTA 2.0):** A field in a message that determines the type. Examples are value payload (TransactionType type), FPC opinion payload (StatementType type), dRNG payload (Payload), Salt declaration payload, generic data payload. -- **Private Tangle:** A private tangle is comparable to a test network under complete control of the operator. This allows companies and developers to test their applications under self-defined environment variables without external influences and protected from prying eyes. There is no interoperability between a private Tangle and the Shimmer Tangle. So, sending from one to the other does not work either. Each private Tangle is an independent network with its own nodes, tokens, and coordinator. -- **Proof of Work (PoW):** A time-consuming (expensive) mathematical calculation that uses computational power to prevent spam attacks. It consists of a difficult cryptographic puzzle that is easy to verify. -- **Proof of Inclusion (PoI):** With PoI, one is able to provide evidence that a transaction was indirectly referenced by another transaction without having to present the full chain of actual transactions between the two transactions. This is done by using a sequence of hashes instead of the actual transaction data to prove the inclusion of a transaction (inclusion) in the referenced subtangle. -- **Pruning:** In computer science, this is a term for simplifying, shortening, and optimizing decision trees. In Shimmer, this is done by local snapshots on each full node. Old transactions that have already been confirmed are deleted from the database, leaving only a file (list) of credits on each address. -- **Public and private keys:** These are used in cryptographic systems which use key pairs. There are public keys which can be shared and private keys which are known only to the owner. The generation of such keys depends on cryptographic algorithms based on mathematical problems to generate one-way functions. Effective security requires keeping the private key to remain only known to the owner. Public keys derived from this private key can be shared and used by others to verify ownership of the private key, without exposing the private key. Public keys function as addresses in Shimmer. - -## R - -- **Rebroadcast:** Repeats the sending of a transaction. While a transaction is being sent to an Shimmer node, it may go offline. In this case, the Shimmer node may not forward the transactions to its neighbors, and the rest of the network will never see these transactions. As a result, that transaction will never be referenced by the coordinator and thus never confirmed. Resending a bundle means resending the same bundle to an Shimmer node. This way you give your transactions another chance to be forwarded to the rest of the network. -- **Reusable Addresses:** With the introduction of the Ed25519 signature scheme, through the IOTA 1.5 Chrysalis upgrade, reusable addresses are now supported. -- **Reattachment:** Resending a transaction by re-selecting a tip and referencing newer tips by repeating PoW. - -## S - -- **Salt:** In cryptography, salt is a randomly chosen string of characters that is appended to a given plaintext before it is further processed to increase the entropy (disorder) of the input. It is often used for storing and transmitting passwords to increase information security. -- **Sandbox:** An isolated area where programs can be tested. -- **Software as a Service (SaaS):** The SaaS model is a subset of cloud computing. It is based on the principle that the software and IT infrastructure can be operated by an external service provider and rented by the customer as a service. -- **Smart Contract:** Smart contracts are contracts or programs that are automatically executed. -- **Smart Contract Chain:** Smart contracts are processed via a so-called contract chain, the representation of the contract state. A smart contract writes its state every time it is requested, and a new block is added for each of these state updates. All these updates are collected and confirmed in one block. So, the chain also contains all the past states. The chain can contain many Smart Contracts, all working on the same global state of the chain. From this perspective, the Contract chain is essentially a blockchain anchored on the Tangle. IOTA Smart Contracts can be considered “classic” Smart Contracts, but with the added feature that you can have multiple such parallel chains all using the same native Shimmer token and trading between them in a trusted manner on the Tangle. This enables trusted interoperability between different applications. -- **Solidification time:** The time of solidification when the entire history of a transaction has been received by a node. -- **Splitting Attacks:** An attack in which a malicious node attempts to split the tangle into two branches. As one of the branches grows, the attacker publishes transactions on the other branch to keep both alive. Splitting attacks attempt to slow down the consensus process or perform double spending. -- **Sharding:** Shimmer nodes have an upper limit on transactions per second (TPS) they can process. Through a type of database partitioning (breaking a very large database into smaller ones) into more manageable segments (shards), each shard would contain a unique set of account balances and nodes would then be assigned to individual shards to validate transactions. The goal is that by dividing into more manageable segments, it will increase transaction throughput and thus overcome scalability issues. -- **Signatures:** Signatures prove ownership of an address. Clients (Wallets) need this proof before nodes validate a transaction. To prove ownership, input transactions must be signed with the private key used to create the address. -- **Solidity (IOTA 2.0):** A message is marked as solid if its entire past cone until the Genesis (or the latest snapshot) is known. -- **Subtangle:** A consistent section of the tangle (i.e., a subset of messages / value objects) such that each contained message / value object also contains its referenced messages / value objects. -- **Streams:** IOTA Streams is a multifunctional second layer data transfer protocol that can be used for various types of data transfer (e.g., streaming data). For example, it allows sensors and other devices to encrypt entire data streams and anchor them in the IOTA Tangle. IOTA’s consensus protocol adds integrity and authenticity to these message streams. Given these characteristics, IOTA Streams fills an important need in industries where integrity, privacy, and immutability collide. -- **Sybil Attack:** An attempt to gain control of a peer-to-peer network by forging multiple false identities. -- **Snapshot:** A special feature of the Tangle. A snapshot deletes all transactions. Only transactions with a balance > 0 are kept. The metadata such as tags and messages are also deleted. What is left behind is just a list of addresses and balances. After a snapshot, the nodes use this list as “genesis”, a new starting point for the tangle. This reduces the size of the tangle network, allowing Shimmer nodes to use less memory. Full nodes perform what are called “Local Snapshots” independently and at their own discretion. - -## T - -- **Tangle:** The Tangle is the underlying core data structure. In mathematical terms it is a directed acyclic graph (DAG). The Tangle is the distributed ledger of Shimmer that stores all transactions. -- **Ternary system:** A trit (trinary digit) can have exactly three states (3 x 1 = 3): -1, 0 and 1. Three trits result in one tryte (33 = 27) and can thus represent 27 combinations. In IOTA, the letters A-Z (26 pieces) and the number 9 are used for this purpose. -- **Token:** The digital currency form (cryptocurrency). It is a powerful tool for value transfer between people and machines. Total number: 2,779,530,283,277,761 IOTA. The base units are Pi, Ti, Gi, Mi, ki, i -- **Trinity (IOTA 1.0):** Depreciated IOTA Wallet -- **Tip:** A transaction that has not yet been approved. -- **Tip Selection:** The process of selecting previous transactions to be referenced by a new transaction. In these references, a transaction ties into the existing data structure. Shimmer only enforces that a transaction approves up to eight other transactions, the tip selection strategy is left to the user (with a good default provided by Shimmer). -- **Tip Transaction:** A solid end transaction that is not yet a parent. -- **Transaction (IOTA 2.0):** A message that contains a Token transfer as a payload. The transferred tokens can be native IOTA Tokens or native IOTA Assets. - -## U - -- **UTXO model:** This is a so-called addressing model. UTXO stands for “unspent transaction output”, which simply means that you not only keep track of the credits on the address, but also keep track of where the credits come from and where they are sent when they are spent. Each token on an address is thus uniquely identifiable and each issue names the exact token they want to move. This enables faster and more accurate conflict handling and improves the resilience and security of the protocol. - -## V - -- **Value Layer (IOTA 2.0):** The Value layer builds on the Communication layer. It works exclusively with payloads of type Value object. This layer has several tasks: Forming the ledger state, processing, validation and output of transactions, conflict detection, conflict resolution via FPC, forming a DAG from value objects, tip selection (on value object tips). -- **Value Transactions:** Value transactions either withdraw Shimmer tokens from an address or deposit them to an address. Nodes must verify these transactions to ensure that the sender actually owns the Shimmer tokens and that additional tokens are never generated. To do this, the following checks are performed: All Shimmer tokens withdrawn from an address are also deposited into one or more other addresses; the value of each transaction does not exceed the total global supply; signatures are valid. -- **Version Number (IOTA 2.0):** Indicates the correct format of each type. - -## W - -- **White-flag approach (IOTA 1.5):** Used to calculate credits. A simpler, conflict-avoiding approach that improves the speed and efficiency of tip selection, eliminates certain attacks, and significantly reduces the need for reattachments. -- **Wasp:** The Wasp node software is an implementation of Smart Contracts on the Shimmer Tangle. diff --git a/shimmer/learn/glossary.mdx b/shimmer/learn/glossary.mdx new file mode 100644 index 00000000000..6686ebb7b0f --- /dev/null +++ b/shimmer/learn/glossary.mdx @@ -0,0 +1,8 @@ +--- +title: Glossary +description: Glossary of all specialized names and phrases used in the IOTA and Shimmer networks. If you dont understand a wording you will find answers here. +--- + +import Glossary from '@theme/Glossary'; + + diff --git a/src/common/css/custom.css b/src/common/css/custom.css index ee8984da045..d0824b60934 100644 --- a/src/common/css/custom.css +++ b/src/common/css/custom.css @@ -64,7 +64,7 @@ padding: 1rem; border-radius: 4px; font-size: 90%; - /*min-width: 250px;*/ + min-width: 250px; max-width: 450px; z-index: 1; } diff --git a/src/common/defaultContentPlugin.js b/src/common/defaultContentPlugin.js index 84e6d46051e..36dd3ba6041 100644 --- a/src/common/defaultContentPlugin.js +++ b/src/common/defaultContentPlugin.js @@ -1,7 +1,7 @@ /** @type {import('@docusaurus/plugin-content-docs').Options} */ module.exports = async () => { const jargonPlugin = (await import('rehype-jargon')).default; - const jargonConfig = (await import('./../../shimmer/jargon.js')).default; + const jargonConfig = (await import('./../../common/jargon.js')).default; return { editUrl: 'https://github.com/iotaledger/iota-wiki/edit/main/', diff --git a/theme/package.json b/theme/package.json index 81f2c4566f5..ebc8033584c 100644 --- a/theme/package.json +++ b/theme/package.json @@ -12,9 +12,11 @@ "test": "jest" }, "dependencies": { + "@artsy/to-title-case": "^1.1.0", "@docusaurus/theme-classic": "2.4.1", "@metamask/providers": "^10.2.1", - "clsx": "^1.2.1" + "clsx": "^1.2.1", + "html-react-parser": "^4.0.0" }, "devDependencies": { "@docusaurus/types": "2.4.1", diff --git a/theme/src/theme/Glossary/index.tsx b/theme/src/theme/Glossary/index.tsx new file mode 100644 index 00000000000..c13206e827f --- /dev/null +++ b/theme/src/theme/Glossary/index.tsx @@ -0,0 +1,55 @@ +import React from 'react'; +import Heading from '@theme/Heading'; +import { toTitleCase } from '@artsy/to-title-case'; +import { clsx } from 'clsx'; + +export default function Glossary() { + const glossary = require('@site/common/jargon.js'); + const parse = require('html-react-parser'); + + const sortedGlossary = Object.keys(glossary) + .sort() + .reduce((acc, key) => { + acc[key] = glossary[key]; + return acc; + }, {}); + + var char = ''; + return ( + <> + {Object.entries(sortedGlossary).map(([key, value]) => { + var heading = null; + if (key.charAt(0) !== char) { + char = key.charAt(0); + heading = char; + } + + return ( + <> + {heading && ( + + {char.toUpperCase()} + + )} + + {toTitleCase(key)} + +

{parse(value)}

+ + ); + })} + + ); +} diff --git a/yarn.lock b/yarn.lock index 7a9fcf9b9fd..ac699c2e654 100644 --- a/yarn.lock +++ b/yarn.lock @@ -224,6 +224,17 @@ __metadata: languageName: node linkType: hard +"@artsy/to-title-case@npm:^1.1.0": + version: 1.1.0 + resolution: "@artsy/to-title-case@npm:1.1.0" + dependencies: + lodash.deburr: ^4.1.0 + lodash.isnumber: ^3.0.3 + lodash.upperfirst: ^4.3.1 + checksum: b67627f89ebe7477a4a9c58a377389a7f0d7b4531355322705e9e056f3d2a518440dbc33374ec4bd49bc7e1fdb2b6318f1d7fee664a91bf255593211eb58927d + languageName: node + linkType: hard + "@babel/code-frame@npm:^7.0.0, @babel/code-frame@npm:^7.10.4, @babel/code-frame@npm:^7.16.0, @babel/code-frame@npm:^7.22.5, @babel/code-frame@npm:^7.8.3": version: 7.22.5 resolution: "@babel/code-frame@npm:7.22.5" @@ -2775,12 +2786,14 @@ __metadata: version: 0.0.0-use.local resolution: "@iota-wiki/theme@workspace:theme" dependencies: + "@artsy/to-title-case": ^1.1.0 "@docusaurus/theme-classic": 2.4.1 "@docusaurus/types": 2.4.1 "@metamask/providers": ^10.2.1 "@types/react": 18.2.14 clsx: ^1.2.1 copyfiles: ^2.4.1 + html-react-parser: ^4.0.0 nodemon: ^2.0.16 prettier: ^2.8.8 react: 18.2.0 @@ -8122,6 +8135,15 @@ __metadata: languageName: node linkType: hard +"domhandler@npm:5.0.3, domhandler@npm:^5.0.2, domhandler@npm:^5.0.3": + version: 5.0.3 + resolution: "domhandler@npm:5.0.3" + dependencies: + domelementtype: ^2.3.0 + checksum: 0f58f4a6af63e6f3a4320aa446d28b5790a009018707bce2859dcb1d21144c7876482b5188395a188dfa974238c019e0a1e610d2fc269a12b2c192ea2b0b131c + languageName: node + linkType: hard + "domhandler@npm:^4.0.0, domhandler@npm:^4.2.0, domhandler@npm:^4.3.1": version: 4.3.1 resolution: "domhandler@npm:4.3.1" @@ -8131,15 +8153,6 @@ __metadata: languageName: node linkType: hard -"domhandler@npm:^5.0.2, domhandler@npm:^5.0.3": - version: 5.0.3 - resolution: "domhandler@npm:5.0.3" - dependencies: - domelementtype: ^2.3.0 - checksum: 0f58f4a6af63e6f3a4320aa446d28b5790a009018707bce2859dcb1d21144c7876482b5188395a188dfa974238c019e0a1e610d2fc269a12b2c192ea2b0b131c - languageName: node - linkType: hard - "domutils@npm:^1.7.0": version: 1.7.0 resolution: "domutils@npm:1.7.0" @@ -8161,7 +8174,7 @@ __metadata: languageName: node linkType: hard -"domutils@npm:^3.0.1": +"domutils@npm:^3.0.1, domutils@npm:^3.1.0": version: 3.1.0 resolution: "domutils@npm:3.1.0" dependencies: @@ -8318,7 +8331,7 @@ __metadata: languageName: node linkType: hard -"entities@npm:^4.2.0, entities@npm:^4.4.0": +"entities@npm:^4.2.0, entities@npm:^4.4.0, entities@npm:^4.5.0": version: 4.5.0 resolution: "entities@npm:4.5.0" checksum: 853f8ebd5b425d350bffa97dd6958143179a5938352ccae092c62d1267c4e392a039be1bae7d51b6e4ffad25f51f9617531fedf5237f15df302ccfb452cbf2d7 @@ -10065,6 +10078,16 @@ __metadata: languageName: node linkType: hard +"html-dom-parser@npm:4.0.0": + version: 4.0.0 + resolution: "html-dom-parser@npm:4.0.0" + dependencies: + domhandler: 5.0.3 + htmlparser2: 9.0.0 + checksum: 95e483b2c945e1158e102e4eb69768124b06c94cf3c0abff8e9b02e146b7391dcdd620df8d54331efb9952c9187e0352ea436226e9ba5f26a0cc3cfe85853d4b + languageName: node + linkType: hard + "html-entities@npm:^2.3.2": version: 2.4.0 resolution: "html-entities@npm:2.4.0" @@ -10089,6 +10112,20 @@ __metadata: languageName: node linkType: hard +"html-react-parser@npm:^4.0.0": + version: 4.0.0 + resolution: "html-react-parser@npm:4.0.0" + dependencies: + domhandler: 5.0.3 + html-dom-parser: 4.0.0 + react-property: 2.0.0 + style-to-js: 1.1.3 + peerDependencies: + react: 0.14 || 15 || 16 || 17 || 18 + checksum: 7e0a65d047236ba0f09f3b0edb6c98bc652829e83c5db5ba494d449cbf2a0f822d461ed6ebe0d9e6812d7b844be177211124a92df1322bcf121f9a34937f3e9a + languageName: node + linkType: hard + "html-tags@npm:^3.2.0": version: 3.3.1 resolution: "html-tags@npm:3.3.1" @@ -10125,6 +10162,18 @@ __metadata: languageName: node linkType: hard +"htmlparser2@npm:9.0.0": + version: 9.0.0 + resolution: "htmlparser2@npm:9.0.0" + dependencies: + domelementtype: ^2.3.0 + domhandler: ^5.0.3 + domutils: ^3.1.0 + entities: ^4.5.0 + checksum: a234c3add821cae8308ca61ce4b8ad3e88af83cf9c3c2003059adc89c46a06ffc39cc2a92b39af8d16c3705e1055df6769d80877acb6529983867f0d7e74098d + languageName: node + linkType: hard + "htmlparser2@npm:^6.1.0": version: 6.1.0 resolution: "htmlparser2@npm:6.1.0" @@ -11646,6 +11695,13 @@ __metadata: languageName: node linkType: hard +"lodash.deburr@npm:^4.1.0": + version: 4.1.0 + resolution: "lodash.deburr@npm:4.1.0" + checksum: 6e2012315c20a4d8ed4f1884ed4b8e6b0093c6355a87bfd95ecf25a5243c8c88d747d67375d52cb87ebc99d090935ed8dc3814c8e661e3275a6dbe02b68efc99 + languageName: node + linkType: hard + "lodash.flow@npm:^3.3.0": version: 3.5.0 resolution: "lodash.flow@npm:3.5.0" @@ -11660,6 +11716,13 @@ __metadata: languageName: node linkType: hard +"lodash.isnumber@npm:^3.0.3": + version: 3.0.3 + resolution: "lodash.isnumber@npm:3.0.3" + checksum: 913784275b565346255e6ae6a6e30b760a0da70abc29f3e1f409081585875105138cda4a429ff02577e1bc0a7ae2a90e0a3079a37f3a04c3d6c5aaa532f4cab2 + languageName: node + linkType: hard + "lodash.memoize@npm:^4.1.2": version: 4.1.2 resolution: "lodash.memoize@npm:4.1.2" @@ -11700,6 +11763,13 @@ __metadata: languageName: node linkType: hard +"lodash.upperfirst@npm:^4.3.1": + version: 4.3.1 + resolution: "lodash.upperfirst@npm:4.3.1" + checksum: cadec6955900afe1928cc60cdc4923a79c2ef991e42665419cc81630ed9b4f952a1093b222e0141ab31cbc4dba549f97ec28ff67929d71e01861c97188a5fa83 + languageName: node + linkType: hard + "lodash@npm:4.17.21, lodash@npm:^4.17.19, lodash@npm:^4.17.20, lodash@npm:^4.17.21, lodash@npm:^4.17.4": version: 4.17.21 resolution: "lodash@npm:4.17.21" @@ -14842,6 +14912,13 @@ plugin-image-zoom@flexanalytics/plugin-image-zoom: languageName: node linkType: hard +"react-property@npm:2.0.0": + version: 2.0.0 + resolution: "react-property@npm:2.0.0" + checksum: 8a444df30ef0937689c7968dae2501a0ca523777169f450e1f7ef5beeb855d6509bd058bf612f6ed8f459aa35468335d356e50264492e1938586e59fdb988262 + languageName: node + linkType: hard + "react-reconciler@npm:^0.26.2": version: 0.26.2 resolution: "react-reconciler@npm:0.26.2" @@ -16610,6 +16687,15 @@ plugin-image-zoom@flexanalytics/plugin-image-zoom: languageName: node linkType: hard +"style-to-js@npm:1.1.3": + version: 1.1.3 + resolution: "style-to-js@npm:1.1.3" + dependencies: + style-to-object: 0.4.1 + checksum: 7aaeacff909d43bbfc28e9a004019224d0eda895ac3d0d9f3160b6ad044dca8d3965f7b2b92ac649f63f62889324b560147d21cf3149f29794692c5d7b207110 + languageName: node + linkType: hard + "style-to-object@npm:0.3.0, style-to-object@npm:^0.3.0": version: 0.3.0 resolution: "style-to-object@npm:0.3.0" @@ -16619,7 +16705,7 @@ plugin-image-zoom@flexanalytics/plugin-image-zoom: languageName: node linkType: hard -"style-to-object@npm:^0.4.0": +"style-to-object@npm:0.4.1, style-to-object@npm:^0.4.0": version: 0.4.1 resolution: "style-to-object@npm:0.4.1" dependencies: From abeabe8703f18e6e98c4e7d2420f870bd3072e4a Mon Sep 17 00:00:00 2001 From: Dr-Electron Date: Mon, 10 Jul 2023 22:08:42 +0200 Subject: [PATCH 4/8] Add example, next and iota section --- common/jargon.js | 2 +- .../zebra-iota-edge-sdk-101-tutorial.md | 2 +- .../zebra-iota-edge-sdk-102-tutorial.md | 2 +- iota/docusaurus.config.js | 6 +- iota/learn/glossary.md | 187 ------------------ iota/learn/glossary.mdx | 8 + .../firefly/faq-and-troubleshooting.md | 2 +- next/docusaurus.config.js | 10 +- next/learn/data-and-value-transfer.md | 2 +- next/learn/glossary.md | 187 ------------------ next/learn/glossary.mdx | 8 + shimmer/docusaurus.config.js | 2 +- shimmer/learn/data-and-value-transfer.md | 2 +- 13 files changed, 33 insertions(+), 387 deletions(-) delete mode 100644 iota/learn/glossary.md create mode 100644 iota/learn/glossary.mdx delete mode 100644 next/learn/glossary.md create mode 100644 next/learn/glossary.mdx diff --git a/common/jargon.js b/common/jargon.js index 70492c7a32c..14adc9ef740 100644 --- a/common/jargon.js +++ b/common/jargon.js @@ -1,7 +1,7 @@ module.exports = { 'address checksum': 'Checksum validation is a way to determine if an address is valid and does not contain typos.', - 'dynamic po': + 'dynamic pow': '(In development for IOTA 1.5 and Shimmer): With this feature, the coordinator can issue a milestone and simultaneously set the future PoW score. This means that if the network is not fully utilized, the PoW will be reduced to the point where it can be executed by microdevices. Accordingly, the coordinator can also raise the PoW difficulty in case of high utilization and thus make an attack very expensive.', 'auto peering': 'A mechanism that allows nodes to automatically select their neighbors without manual intervention by the node operator.', diff --git a/iota/docs/zebra-iota-edge-sdk/tutorials/zebra-iota-edge-sdk/zebra-iota-edge-sdk-101-tutorial.md b/iota/docs/zebra-iota-edge-sdk/tutorials/zebra-iota-edge-sdk/zebra-iota-edge-sdk-101-tutorial.md index 7a1e40a2db4..30783676902 100644 --- a/iota/docs/zebra-iota-edge-sdk/tutorials/zebra-iota-edge-sdk/zebra-iota-edge-sdk-101-tutorial.md +++ b/iota/docs/zebra-iota-edge-sdk/tutorials/zebra-iota-edge-sdk/zebra-iota-edge-sdk-101-tutorial.md @@ -59,7 +59,7 @@ There are several applications of decentralized identities in different domains: - **Decentralized Identity (DID) for Organizations**: The main application is the “DID for organizations in global trade” use case. For instance, a trader from Kenya creates its decentralized digital identity (DID) and receives a number of Credentials from Kenyan authorities after the requested verification processes. Some of these Credentials are also accepted by the EU authorities. Once starting to trade in Argentina, the same trader does not require new credentials as the existing ones are already matching those required by the Argentinian authorities, who can verify their authenticity in a decentralized way, without the need to integrate with any of the Kenya or EU Identity Issuers. You can watch this video which shows how we are applying it to the [TLIP Project](https://www.youtube.com/watch?v=bnAfclXTaeI) jointly developed by TradeMark East Africa and IOTA. -- **Decentralized Device Identity**. Any device, such as a printer, scanner or RFID reader used in supply chains, may be issued a decentralized identity and associated credentials by the organization owning it. As a result all interactions made with that device can be recorded and audited, increasing the level of traceability, accountability, security and trust in the daily operations of an organization. For instance, a Zebra scanner in a warehouse can be assigned a decentralized identity, including certain verifiable credentials. When the device generates supply chain events, for instance scanning trade items (pallets, cases, etc.), a new record, signed with the keys bound to the identity of such a device, can be recorded and anchored to a distributed ledger such as IOTA. As a result, any associated business operation could be traceable all the way from an origin device to the corresponding business transaction. The Zebra-IOTA SDK already includes a reference application (_[DeviceID Application](zebra-iota-edge-sdk-104-tutorial.md)_) structured around a wizard that allows onboarding devices owned by an organization (see below). +- **Decentralized Device Identity**. Any device, such as a printer, scanner or RFID reader used in supply chains, may be issued a decentralized identity and associated credentials by the organization owning it. As a result all interactions made with that device can be recorded and audited, increasing the level of traceability, accountability, security and trust in the daily operations of an organization. For instance, a Zebra scanner in a warehouse can be assigned a decentralized identity, including certain verifiable credentials. When the device generates supply chain events, for instance scanning trade items (pallets, cases, etc.), a new record, signed with the keys bound to the identity of such a device, can be recorded and anchored to a distributed ledger such as IOTA. As a result, any associated business operation could be traceable all the way from an origin device to the corresponding business transaction. The Zebra-IOTA SDK already includes a reference application ([DeviceID Application](zebra-iota-edge-sdk-104-tutorial.md)) structured around a wizard that allows onboarding devices owned by an organization (see below). - **Supply Chain Credentials**. Currently there are many supply chain processes that are actually conducted without the proper level of security or with no digitisation at all. We can imagine a truck driver arriving into a warehouse requesting to load / unload some pallets and showing just a document on paper with the transportation order. These kind of processes involve identity, trust and change of custody records between multiple parties each one holding their own decentralized identity: the warehouse manager, the truck driver, the logistics service provider, the supplier company and the customer company, for instance: diff --git a/iota/docs/zebra-iota-edge-sdk/tutorials/zebra-iota-edge-sdk/zebra-iota-edge-sdk-102-tutorial.md b/iota/docs/zebra-iota-edge-sdk/tutorials/zebra-iota-edge-sdk/zebra-iota-edge-sdk-102-tutorial.md index 96aaebeae6b..7899c5c4a59 100644 --- a/iota/docs/zebra-iota-edge-sdk/tutorials/zebra-iota-edge-sdk/zebra-iota-edge-sdk-102-tutorial.md +++ b/iota/docs/zebra-iota-edge-sdk/tutorials/zebra-iota-edge-sdk/zebra-iota-edge-sdk-102-tutorial.md @@ -10,7 +10,7 @@ Before reading this tutorial we recommend that you read the [first part](../zebr All the scaffolding needed to create a solution for managing credentials on Android devices is packaged under the so-called _Holder Application_. This application also allows sharing credentials with interested parties by way of a scannable data matrix. -The application guides the user to set up an Identity (a DID document) before associating Verifiable Credentials to this Identity. As this is just a reference application, the app self-signs the Verifiable Credentials, but ordinarily they would be signed by a third party such as a government in the case of personal details. An interested party can scan and verify the credential when presented in the form of a data matrix (see _[103 Tutorial](../zebra-iota-edge-sdk/zebra-iota-edge-sdk-103-tutorial.md)_). +The application guides the user to set up an Identity (a DID document) before associating Verifiable Credentials to this Identity. As this is just a reference application, the app self-signs the Verifiable Credentials, but ordinarily they would be signed by a third party such as a government in the case of personal details. An interested party can scan and verify the credential when presented in the form of a data matrix (see [103 Tutorial](../zebra-iota-edge-sdk/zebra-iota-edge-sdk-103-tutorial.md)). Note: The _Holder Application_ also includes partial functionality as an issuer of credentials (see [104 Tutorial](../zebra-iota-edge-sdk/zebra-iota-edge-sdk-104-tutorial.md)). diff --git a/iota/docusaurus.config.js b/iota/docusaurus.config.js index 47e472a2efa..40397a44cd8 100644 --- a/iota/docusaurus.config.js +++ b/iota/docusaurus.config.js @@ -3,8 +3,10 @@ const contentConfigs = require('./contentPlugins'); const { create_doc_plugin, globStatic } = require('../src/utils/config'); module.exports = async () => { - const contentPlugins = (await contentConfigs()).map((contentConfig) => - create_doc_plugin(contentConfig), + const contentPlugins = await Promise.all( + (await contentConfigs()).map( + async (contentConfig) => await create_doc_plugin(contentConfig), + ), ); const staticDirs = await globStatic('/docs/**/static/', __dirname); diff --git a/iota/learn/glossary.md b/iota/learn/glossary.md deleted file mode 100644 index 313e6244420..00000000000 --- a/iota/learn/glossary.md +++ /dev/null @@ -1,187 +0,0 @@ ---- -title: Glossary -description: Glossary of all specialized names and phrases used in the IOTA - Technology. If you dont understand a wording you will find answers here. ---- - -# Glossary - -## A - -- **Address Checksum:** Checksum validation is a way to determine if an address is valid and does not contain typos. -- **Adaptive PoW** (In development for IOTA 1.5): With this feature, the coordinator can issue a milestone and simultaneously set the future PoW score. This means that if the network is not fully utilized, the PoW will be reduced to the point where it can be executed by microdevices. Accordingly, the coordinator can also raise the PoW difficulty in case of high utilization and thus make an attack very expensive. -- **Auto peering:** A mechanism that allows nodes to automatically select their neighbors without manual intervention by the node operator. -- **API(Application Programming Interfaces):** The way for applications to interact with the Tangle. -- **Atomic Transactions:** Instead of the bundle construct, IOTA 1.5 uses simpler Atomic Transactions. An Atomic Transaction includes everything related to a transaction in a single message instead of splitting it up (Bundles). This reduces network overhead and signature verification load, improves spam protection and rate control, and shortens the length of Merkle proofs (for future sharding). It also reduces implementation overhead and increases maintainability of the core node software. -- **Application Layer (IOTA 2.0):** The top layer of the 3-layer communication protocol. The IOTA protocol allows a variety of external applications to run on the Message Tangle. Anyone can design an application and users can decide which applications to run on their nodes. These applications will all use the communication layer to transmit and store data. -- **Approval Switch (IOTA 2.0):** When a message is selected as a parent, we can choose from the strong or weak tip pool. This mechanism is called Approval Switch. -- **Approval Weight (IOTA 2.0):** A message gets Mana-weight by approving the message directly or indirectly. However, only strong parents can pass on the mana weight to the past, while weak parents receive the weight from their weak children but do not pass it on. -- **Approvers (IOTA 2.0):** Parents are approved by their referencing messages called approvers. It is thus a reverse mapping of parents. As in the parents’ definition, an approver might be either strong or weak. - -## B - -- **Balance:** Funds on the addresses (account). These are always available and cannot be deleted or forgotten. -- **Blockchain Bottleneck:** The more transactions are issued, the more the block rate and size become a bottleneck in the system. It is no longer possible to capture all incoming transactions in a prompt manner. Attempts to speed up block rates result in more orphaned blocks (blocks are left behind) and reduce the security of the blockchain. -- **Branch (IOTA 2.0):** A version of the ledger that temporarily coexists with other versions, each spawned by conflicting transactions. -- **Bootstrapping attack:** An attack in which a node downloads malicious snapshot files, including invalid transactions and balances. - -## C - -- **Curl:** This is one of the hash functions currently in use. It is based on the “sponge” construction of the Keccak inventors (SHA-3). -- **Confirmed:** Confirmed transactions. In IOTA 1.5, messages in the Tangle are considered for confirmation only when they are directly or indirectly referenced by a milestone that the Coordinator node has validated. To allow the nodes to recognize the milestones, all nodes that participate in the same IOTA network are configured with the Merkle root address of a Coordinator that they trust to confirm messages. Using this address, nodes can validate the signatures in milestones to verify whether the trusted Coordinator signs them. To make sure that new messages always have a chance of being confirmed, the Coordinator sends indexed milestones at regular intervals. This way, nodes can compare the indexes of their milestones to check whether they are synchronized with the rest of the network. -- **CTPS:** Confirmed transactions per second. -- **Cumulative Weight:** A system for valuing transactions. Each additional transaction that references a transaction increases its cumulative weight. When tips are selected, a path through transactions that has a higher cumulative weight is preferred. -- **Chronicle:** A permanode solution of the IOTA Foundation. It allows to store all transactions reaching a node in a distributed database that is secure and scales well. Chronicle is used to store the Tangle’s unlimited data flow and make it queryable. In other words, permanence allows the entire history of the Tangle to be stored indefinitely and makes that data easily accessible. -- **Consensus:** Agreement on a specific date or value in distributed multi-agent systems, in the presence of faulty processes. -- **Coordinator (only up to IOTA 2.0):** A trusted entity, as protection against malicious transactions. The Tangle is not yet a final product, it is still in beta. The network currently relies on a kind of shield, the so-called coordinator. It is open-source and runs on a Hornet node. The COO acts as a centralized, voluntary, and temporary alternative consensus mechanism for the Tangle. To do this, the COO sends honest transactions to the full nodes at regular intervals. These packets contain a signed message with no value, called a milestone. The full nodes in the Tangle consider a transaction as confirmed only if it is approved by a milestone. Important: The coordinator can only confirm transactions, but he cannot bypass the consensus rules. To create, freeze or steal tokens is not possible for him. This fixed rule and the COO address is hardcoded on each full node, so the coordinator’s influence on the tangle is very limited, since the tangle is also constantly monitored by all the other full nodes. > The Coo will be switched off with the IOTA 2.0 upgrade. -- **Communication Layer (IOTA 2.0):** This layer stores and communicates information. This layer contains the distributed ledger or tangle. The rate control and timestamps are also located in this layer. -- **Core Object type (IOTA 2.0):** An object type that must be parsed by all nodes. Parsers are computer programs responsible for decomposing and converting an input into a format more suitable for further processing. -- **Core Application (IOTA 2.0):** Core application that must be executed by all nodes, for example the value transfer application. -- **Child (IOTA 2.0):** A transaction that gets referenced by Parents. -- **Chrysalis:** The name of the IOTA 1.5 network upgrade. - -## D - -- **Data:** The tangle is a way of proving the integrity of data (verifiability of completeness and origin) in a trustworthy manner. At present, there are several cryptographic methods that make this possible, but security gaps are repeatedly discovered here, making data vulnerable to manipulation. This is a major problem, especially in cloud computing, where third-party audit tools are sometimes even used (for a fee) to ensure this data integrity. This is exactly where IOTA comes in and offers a relatively easy way to escape this with its protocol and without fees. -- **Data transactions:** These are confirmed directly and are notarized. With the help of “notarization”, it can be proven that an electronic document existed in a certain form at a certain time and has not been changed since its creation. When a notarization is created, a unique hash (fingerprint) of a document is calculated and stored together with a timestamp in the IOTA ledger (tangle) in an immutable manner. -- **Data storage:** Just like the internet, the IOTA protocol does not store data or in other words, the Tangle is not a data storage. If someone wants to store the history of transactions in a decentralized way, they can build a second-layer solution for this themselves or pay third parties for this storage. For the basic layer, IOTA focuses on performance, throughput, and security rather than building a global database. -- **Distributed Ledger Technology (DLT):** This is a database architecture that allows owners of digital assets to transfer and document them from peer to peer. Each transfer in a DLT is stored as a record in a distributed ledger (database). This database is stored in all nodes of a network. -- **DevNet:** The DevNet (developer network) is a pure test network to research and test a Tangle without Coordinator. -- **Decay:** Both Mana and pending Mana decay proportionally to its value, preventing Mana from growing indefinitely over time. -- **Double-spending:** Double-spending is a threat to a digital money system, where the same single digital token can be spent more than once. Unlike physical money, a digital token consists of a digital file that can be duplicated or counterfeited. -- **dRNG (Decentralized Random Number Generator):** This random number generator is required in Fast Probabilistic Consensus (FPC) to make the consensus model more resilient to attacks. In the case of conflicting transactions, the FPC votes on the transactions in question in several rounds. The threshold at which a node changes its mind in this vote is 50% +/- a small random deviation (using dRNG). In order to avoid stalemate or a specific outcome in the voting, this additional random component prevents potentially malicious nodes from influencing the voting process. -- **Dust Protection (IOTA 1.5):** Someone who wants to harm IOTA could automatically send 1i for years to repeatedly recreated addresses, driving up the ledger’s memory requirements to the point where a full-node would eventually only run on large servers. In Chrysalis if you want to create a microtransaction (<1Mi) you need to activate dust on the receiving address. That will allow you to receive a certain amount of dust. Also, the addresses with Colored Coins have to be tokenized. After the Coordicide, there will be another solution for IOTA 2.0. -- **Directed Acyclic Graph (DAG):** A directed acyclic graph is DLT structure that consists of edges and vertices that never form a closed loop. The IOTA architecture "the Tangle" is a form of directed acyclic graph. - -## E - -- **Eclipse attack:** A cyber-attack that aims to isolate a specific node rather than attack the entire network. -- **ETH Virtual Machine:** A VM is what executes the Smart Contract code so that it runs deterministically. The language in which you run the code provides hooks to access the sandbox on which the VM runs. In the case of IOTA, this is the ISCP sandbox, which only provides access to IOTA tokens, thus consensus also runs on IOTA tokens. It is only the VM that IOTA works with, foreign tokens have nothing to do with a VM running the SC code, not the ETH VM, nor the Cartesi VM. -- **Epoch (IOTA 2.0):** A time interval used for a specific type of consensus mana. At the end of each epoch, a snapshot is taken of the state of mana distribution on the network. Since this tool uses the timestamp of messages, each node can eventually reach a consensus on the mana distribution of an epoch. - -## F - -- **Faucet:** A pool of tokens (funds). Upon uncomplicated request, one gets a limited number of tokens for testing, especially for developers of own apps this is a great help. -- **Firefly:** Firefly is a wallet, intended to serve as a platform for the current and future IOTA ecosystem. -- **Finality:** The property that once a transaction has been completed, there is no way to reverse or change it. This is the moment when the parties involved in a transfer can consider the transaction completed. Finality can be deterministic or probabilistic. -- **Full nodes (Hornet):** They form the core (infrastructure) of the IOTA network. In order to participate in the peer-to-peer network, the full node must always be online and connected to neighbors (other full nodes). In addition, the transaction database must be synchronized with all other full nodes in the network. The role of full nodes is to interact with clients (wallets, DApps, etc.) and attach their transactions to the ledger, make transactions known to all other full nodes in the network, validate transactions and store them in the ledger. -- **Future Cone:** All messages that directly or indirectly reference a message are called its future cone. -- **Fork:** In IT, this is a new development branch after a project is split into a second follow-on project; the source code or parts of it are developed independently of the original parent project. -- **FPC(Fast Probabilistic Consensus):** Consensus that uses a random number and node opinions to reach consensus. In On-Tangle Voting, it is only used in a specific edge case. Check out OTVFPCS. - -## G - -- **Genesis transaction:** The Genesis transaction is the first transaction that created all IOTA tokens and distributed them to the addresses of the buyers. -- **GoShimmer (No Main net):** Prototype of the coordinator less version of IOTA written in the Go programming language. GoShimmer implements the various modules of Coordicide, such as auto peering, node identities, Mana, etc. GoShimmer serves as a test environment for the first alpha version and the test network. Everything tested here will be gradually merged with Hornet. -- **Generic Data Object (IOTA 2.0):** The most basic object type. All unrecognized data objects are defined this way. - -## H - -- **History:** The list of transactions that were directly or indirectly authorized by a particular transaction. -- **Hash values:** Checksums that are applied to the encryption of messages of variable length. Hash values are like fingerprints of a very long data set. Each message is assigned a very specific hash value. -- **Hooks:** An interface that allows foreign program code to be integrated into an existing application to extend it, change its flow, or intercept certain events. -- **Hornet Node (IOTA 1.5):** Community-developed IOTA Node written in the Go programming language. In addition, the coordinator also runs as a plugin via Hornet. - -## I - -- **Inclusion state:** Used to determine if a transaction has been accepted and confirmed by the network. Especially for a transaction and a list of tips: Inclusion state is true if the tip refers to this transaction. - -## L - -- **Local Snapshots:** Local snapshots are used to limit the memory requirements of the nodes. For this purpose, on the individual nodes old, already confirmed, transactions are deleted from the database. What remains is only a small file (list) with the balances on the respective addresses. Nodes perform the snapshot independently and at their own discretion. This feature allows faster synchronization, lower system resource requirements and no more waiting for global snapshots to clean up the database. -- **Layer:** In DLT a 2nd-layer refers to a secondary framework or protocol built on top of an existing distributed ledger. On these second layers, other applications can be executed without putting too much strain on the base layer. In IOTA, for example, these are the Smart Contracts and IOTA Streams. -- **Local Modifiers:** User-defined conditions that can be considered by nodes during tip selection. In IOTA, nodes do not necessarily have the same view of the tangle. Different types of information that are only available to them locally can be used to strengthen security. - -## M - -- **Merkle Tree:** A Merkle tree is a data structure used in computer science applications. In cryptocurrencies, Merkle trees are used to encode more efficiently and securely. -- **Mainnet:** The public usable IOTA network, in which the IOTA tokens are used that are traded on cryptocurrency exchanges. -- **Milestone (IOTA 1.5):** Milestones are messages that are signed and issued by the coordinator. Their main goal is to help the Tangle grow healthily and guarantee finality. When milestones directly or indirectly approve a transaction in the Tangle, nodes mark the status of that transaction and its entire history as confirmed. -- **Message:** A message is a core data type that reflects a vertex in the communication layer DAG. It contains the following properties: References to other messages, the sender’s public key, the issuing time of the message, the message sequence number from the node that issued the message, the payload that can be interpreted by higher layers, the nonce that the message uses to satisfy the PoW requirement, a signature that signs all of the above fields. A message is not forwarded until it becomes “solid”, i.e., its history is known to the node. Messages must meet a PoW requirement, which currently is to find a nonce so that the hash of the message’s fields (minus the signature) has a certain number of leading zeros. -- **Message overhead:** The additional information (metadata) that must be sent along with the actual information (data). This can include signatures, polls and anything that is transmitted over the network but is not the transaction itself. -- **Mana (IOTA 2.0):** When a value transaction is processed, a quantity called Mana will be “pledged” to a specified node ID. This quantity is related to the amount of IOTA moved into the transaction. The only way to gain Mana is to convince some token holder to pledge it to you. In this sense, Mana is Delegated Proof of Token Ownership. Mana, therefore, provides adequate Sybil protection because it is difficult to acquire it in arbitrary amounts. -- **Markers (IOTA 2.0):** A tool that exists only locally and allows certain calculations to be performed more efficiently, such as the calculation of the approval weight or the presence of certain messages in the past or future cone of another message. -- **Messages per Second (MPS):** The amount of messages issued to the network every second. - -## N - -- **Nakamoto Consensus:** Named after the creator of Bitcoin, Satoshi Nakamoto, the Nakamoto Consensus describes the replacement of coordination / communication between known agents with a cryptographic puzzle (Proof-of-Work). Completion of the puzzle determines which agent acts next. -- **Neighbors:** Network nodes that are directly connected and can exchange messages without intermediate nodes. -- **Nodes:** A node is any computer that connects to other nodes in the network via software. In principle, they serve as a connection point for data transfers. The Tangle works with different types of nodes, such as full nodes like Hornet, permanodes (Chronicle) or smart contract nodes (Wasp). -- **Network Layer (IOTA 2.0):** This layer manages the lower layers of Internet communication such as TCP. In this layer, the connections between the nodes are managed by the Auto peering and Peer Discovery modules and the Gossip protocol. -- **Network ID:** The network ID enables user-specific subtangles in which nodes can only recognize messages from the network ID listed in their configuration file. - -## O - -- **Orphan:** A transaction (or block) that is not referenced by any subsequent transaction (or block). An orphan is not considered confirmed and will not be part of the consensus. -- **Object (IOTA 2.0):** the most basic unit of information in the IOTA protocol. Each object has a type and size and contains data. -- **Oracles:** Oracles are designed to build a secure bridge between the digital and physical worlds in a decentralized, permissionless way. They bring off-chain data to decentralized applications and smart contracts on the IOTA network. -- **OTV (IOTA 2.0):** On Tangle Voting is the official name for the multiverse consensus described by Hans Moog. It is a new consensus mechanism that allows nodes to vote on conflicts directly by publishing a message to the tangle. -- **OTVFPCS (IOTA 2.0):** On Tangle Voting with FPCS (Fast Probabilistic Consensus on a Set) is a mechanism for breaking metastability, which can be used in addition to OTV (On Tangle Voting). Generally, in IOTA2.0, reaching a high approval weight is the finality criteria. If the approval weight is high enough, the message / transaction is finalized. With OTVFPC the initial opinion is created with OTV, if after some time the opinions of the nodes are still split, for whatever reason, FPC is activated to break this metastable state. The finality of value transactions should be reached faster this way. - -## P - -- **Parents:** A message directly references up to 8 previous messages that we call its parents. In IOTA 2.0 a parent can be either strong or weak (see approval switch). -- **Parallel reality ledger state (IOTA 2.0):** This state is used to track conflicts in the tangle. Two new ledger entries that are causally valid but in conflict with each other (ex. Double Spend) are posted into two separate “realities” for this purpose, representing possible but mutually exclusive future ledger states. The consensus mechanism (with FPC, etc.) will now operate until the perception of most nodes tilts in one direction and one of the two possible ledger states is accepted as true. -- **Partition Tolerant:** This means that a part of the Tangle can be disconnected from the main tangle for a certain time and continue to run without an Internet connection. These parts can be reconnected to the main Tangle when the Internet connection is restored. -- **Past Cone:** All messages that are directly or indirectly referenced by a message are called its past cone. -- **Parasite Chain Attacks:** A double spending attack on the Tangle. Here, an attacker attempts to reverse a transaction by setting up an alternate Tangle in which the funds were not spent. He then tries to get the majority of the network to accept the alternative Tangle as the legitimate one. -- **Permanode:** This type of node permanently stores the entire transaction history, possibly with the help of external storage solutions, and possibly only specific transactions (selective permanode). -- **Pending:** A transaction has been seen by the network but not yet confirmed. -- **Peer to Peer Network:** A decentralized network of different network nodes that are connected to each other and exchange data. -- **Peering:** The process of discovering and connecting to other network nodes. -- **Payload (IOTA 2.0):** A field in a message that determines the type. Examples are value payload (TransactionType type), FPC opinion payload (StatementType type), dRNG payload (Payload), Salt declaration payload, generic data payload. -- **Private Tangle:** A private tangle is comparable to a test network under complete control of the operator. This allows companies and developers to test their applications under self-defined environment variables without external influences and protected from prying eyes. There is no interoperability between a private Tangle and the IOTA Tangle. So, sending from one to the other does not work either. Each private Tangle is an independent network with its own nodes, tokens, and coordinator. -- **Proof of Work (PoW):** A time-consuming (expensive) mathematical calculation that uses computational power to prevent spam attacks. It consists of a difficult cryptographic puzzle that is easy to verify. -- **Proof of Inclusion (PoI):** With PoI, one is able to provide evidence that a transaction was indirectly referenced by another transaction without having to present the full chain of actual transactions between the two transactions. This is done by using a sequence of hashes instead of the actual transaction data to prove the inclusion of a transaction (inclusion) in the referenced subtangle. -- **Pruning:** In computer science, this is a term for simplifying, shortening, and optimizing decision trees. In IOTA, this is done by local snapshots on each full node. Old transactions that have already been confirmed are deleted from the database, leaving only a file (list) of credits on each address. -- **Public and private keys:** These are used in cryptographic systems which use key pairs. There are public keys which can be shared and private keys which are known only to the owner. The generation of such keys depends on cryptographic algorithms based on mathematical problems to generate one-way functions. Effective security requires keeping the private key to remain only known to the owner. Public keys derived from this private key can be shared and used by others to verify ownership of the private key, without exposing the private key. Public keys function as addresses in IOTA. - -## R - -- **Rebroadcast:** Repeats the sending of a transaction. While a transaction is being sent to an IOTA node, it may go offline. In this case, the IOTA node may not forward the transactions to its neighbors, and the rest of the network will never see these transactions. As a result, that transaction will never be referenced by the coordinator and thus never confirmed. Resending a bundle means resending the same bundle to an IOTA node. This way you give your transactions another chance to be forwarded to the rest of the network. -- **Reusable Addresses:** With the introduction of the Ed25519 signature scheme, through the IOTA 1.5 Chrysalis upgrade, reusable addresses are now supported. -- **Reattachment:** Resending a transaction by re-selecting a tip and referencing newer tips by repeating PoW. - -## S - -- **Salt:** In cryptography, salt is a randomly chosen string of characters that is appended to a given plaintext before it is further processed to increase the entropy (disorder) of the input. It is often used for storing and transmitting passwords to increase information security. -- **Sandbox:** An isolated area where programs can be tested. -- **Software as a Service (SaaS):** The SaaS model is a subset of cloud computing. It is based on the principle that the software and IT infrastructure can be operated by an external service provider and rented by the customer as a service. -- **Smart Contract:** Smart contracts are contracts or programs that are automatically executed. -- **Smart Contract Chain:** Smart contracts are processed via a so-called contract chain, the representation of the contract state. A smart contract writes its state every time it is requested, and a new block is added for each of these state updates. All these updates are collected and confirmed in one block. So, the chain also contains all the past states. The chain can contain many Smart Contracts, all working on the same global state of the chain. From this perspective, the Contract chain is essentially a blockchain anchored on the Tangle. IOTA Smart Contracts can be considered “classic” Smart Contracts, but with the added feature that you can have multiple such parallel chains all using the same native IOTA token and trading between them in a trusted manner on the Tangle. This enables trusted interoperability between different applications. -- **Solidification time:** The time of solidification when the entire history of a transaction has been received by a node. -- **Splitting Attacks:** An attack in which a malicious node attempts to split the tangle into two branches. As one of the branches grows, the attacker publishes transactions on the other branch to keep both alive. Splitting attacks attempt to slow down the consensus process or perform double spending. -- **Sharding:** IOTA nodes have an upper limit on transactions per second (TPS) they can process. Through a type of database partitioning (breaking a very large database into smaller ones) into more manageable segments (shards), each shard would contain a unique set of account balances and nodes would then be assigned to individual shards to validate transactions. The goal is that by dividing into more manageable segments, it will increase transaction throughput and thus overcome scalability issues. -- **Signatures:** Signatures prove ownership of an address. Clients (Wallets) need this proof before nodes validate a transaction. To prove ownership, input transactions must be signed with the private key used to create the address. -- **Solidity (IOTA 2.0):** A message is marked as solid if its entire past cone until the Genesis (or the latest snapshot) is known. -- **Subtangle:** A consistent section of the tangle (i.e., a subset of messages / value objects) such that each contained message / value object also contains its referenced messages / value objects. -- **Streams:** IOTA Streams is a multifunctional second layer data transfer protocol that can be used for various types of data transfer (e.g., streaming data). For example, it allows sensors and other devices to encrypt entire data streams and anchor them in the IOTA Tangle. IOTA’s consensus protocol adds integrity and authenticity to these message streams. Given these characteristics, IOTA Streams fills an important need in industries where integrity, privacy, and immutability collide. -- **Sybil Attack:** An attempt to gain control of a peer-to-peer network by forging multiple false identities. -- **Snapshot:** A special feature of the Tangle. A snapshot deletes all transactions. Only transactions with a balance > 0 are kept. The metadata such as tags and messages are also deleted. What is left behind is just a list of addresses and balances. After a snapshot, the nodes use this list as “genesis”, a new starting point for the tangle. This reduces the size of the tangle network, allowing IOTA nodes to use less memory. Full nodes perform what are called “Local Snapshots” independently and at their own discretion. - -## T - -- **Tangle:** The Tangle is the underlying core data structure. In mathematical terms it is a directed acyclic graph (DAG). The Tangle is the distributed ledger of IOTA that stores all transactions. -- **Ternary system:** A trit (trinary digit) can have exactly three states (3 x 1 = 3): -1, 0 and 1. Three trits result in one tryte (33 = 27) and can thus represent 27 combinations. In IOTA, the letters A-Z (26 pieces) and the number 9 are used for this purpose. -- **Token:** The digital currency form (cryptocurrency). It is a powerful tool for value transfer between people and machines. Total number: 2,779,530,283,277,761 IOTA. The base units are Pi, Ti, Gi, Mi, ki, i -- **Trinity (IOTA 1.0):** Depreciated IOTA Wallet -- **Tip:** A transaction that has not yet been approved. -- **Tip Selection:** The process of selecting previous transactions to be referenced by a new transaction. In these references, a transaction ties into the existing data structure. IOTA only enforces that a transaction approves up to eight other transactions, the tip selection strategy is left to the user (with a good default provided by IOTA). -- **Tip Transaction:** A solid end transaction that is not yet a parent. -- **Transaction (IOTA 2.0):** A message that contains a Token transfer as a payload. The transferred tokens can be native IOTA Tokens or native IOTA Assets. - -## U - -- **UTXO model:** This is a so-called addressing model. UTXO stands for “unspent transaction output”, which simply means that you not only keep track of the credits on the address, but also keep track of where the credits come from and where they are sent when they are spent. Each token on an address is thus uniquely identifiable and each issue names the exact token they want to move. This enables faster and more accurate conflict handling and improves the resilience and security of the protocol. - -## V - -- **Value Layer (IOTA 2.0):** The Value layer builds on the Communication layer. It works exclusively with payloads of type Value object. This layer has several tasks: Forming the ledger state, processing, validation and output of transactions, conflict detection, conflict resolution via FPC, forming a DAG from value objects, tip selection (on value object tips). -- **Value Transactions:** Value transactions either withdraw IOTA tokens from an address or deposit them to an address. Nodes must verify these transactions to ensure that the sender actually owns the IOTA tokens and that additional tokens are never generated. To do this, the following checks are performed: All IOTA tokens withdrawn from an address are also deposited into one or more other addresses; the value of each transaction does not exceed the total global supply; signatures are valid. -- **Version Number (IOTA 2.0):** Indicates the correct format of each type. - -## W - -- **White-flag approach (IOTA 1.5):** Used to calculate credits. A simpler, conflict-avoiding approach that improves the speed and efficiency of tip selection, eliminates certain attacks, and significantly reduces the need for reattachments. -- **Wasp:** The Wasp node software is an implementation of Smart Contracts on the IOTA Tangle. diff --git a/iota/learn/glossary.mdx b/iota/learn/glossary.mdx new file mode 100644 index 00000000000..6686ebb7b0f --- /dev/null +++ b/iota/learn/glossary.mdx @@ -0,0 +1,8 @@ +--- +title: Glossary +description: Glossary of all specialized names and phrases used in the IOTA and Shimmer networks. If you dont understand a wording you will find answers here. +--- + +import Glossary from '@theme/Glossary'; + + diff --git a/iota/use/wallets/firefly/faq-and-troubleshooting.md b/iota/use/wallets/firefly/faq-and-troubleshooting.md index 8641d9f32aa..a1a041f6cf5 100644 --- a/iota/use/wallets/firefly/faq-and-troubleshooting.md +++ b/iota/use/wallets/firefly/faq-and-troubleshooting.md @@ -301,7 +301,7 @@ If any part of the process is aborted or fails, it can be redone! If something s IMPORTANT: Never share personal information regarding the number of tokens you own, their type, or where and how you keep them, how you secure them, including passwords, recovery passphrases, and user names of wallet accounts or exchanges. Do NOT share that information with anyone – including members of the IOTA Foundation. -Read more about "Security During Token Migration" on Chrysalis [here](https://blog.iota.org/security-during-token-migration/). +Read more about "Security During Token Migration" on _Chrysalis_ [here](https://blog.iota.org/security-during-token-migration/). #### If I have multiple addresses associated with one seed, will the Chrysalis migration send all of my tokens to one address? diff --git a/next/docusaurus.config.js b/next/docusaurus.config.js index ef4b360bac7..4120038922f 100644 --- a/next/docusaurus.config.js +++ b/next/docusaurus.config.js @@ -2,11 +2,13 @@ const path = require('path'); const contentConfigs = require('./contentPlugins'); const { create_doc_plugin, globStatic } = require('../src/utils/config'); -const contentPlugins = contentConfigs.map((contentConfig) => - create_doc_plugin(contentConfig), -); - module.exports = async () => { + const contentPlugins = await Promise.all( + contentConfigs.map( + async (contentConfig) => await create_doc_plugin(contentConfig), + ), + ); + const staticDirs = await globStatic('/docs/**/static/', __dirname); return { diff --git a/next/learn/data-and-value-transfer.md b/next/learn/data-and-value-transfer.md index 49d9d38e403..bcdfd89cc88 100644 --- a/next/learn/data-and-value-transfer.md +++ b/next/learn/data-and-value-transfer.md @@ -37,7 +37,7 @@ The node selects these blocks by using an algorithm called **Uniform Random Tip :::tip Send Data -The Stardust protocol allows you to attach [metadata](outputs.md#metadata) to any transaction. +The _Stardust_ protocol allows you to attach [metadata](outputs.md#metadata) to any transaction. ::: diff --git a/next/learn/glossary.md b/next/learn/glossary.md deleted file mode 100644 index 0a4edbdf10b..00000000000 --- a/next/learn/glossary.md +++ /dev/null @@ -1,187 +0,0 @@ ---- -title: Glossary -description: Glossary of all specialized names and phrases used in the Shimmer Technology. If you dont understand a wording you will find answers here. ---- - -# Glossary - -## A - -- **Address Checksum:** Checksum validation is a way to determine if an address is valid and does not contain typos. -- **Dynamic PoW** (In development for Shimmer): With this feature, the coordinator can issue a milestone and simultaneously set the future PoW score. This means that if the network is not fully utilized, the PoW will be reduced to the point where it can be executed by microdevices. Accordingly, the coordinator can also raise the PoW difficulty in case of high utilization and thus make an attack very expensive. -- **Auto peering:** A mechanism that allows nodes to automatically select their neighbors without manual intervention by the node operator. -- **API(Application Programming Interfaces):** The way for applications to interact with the Tangle. -- **Atomic Transactions:** Instead of the bundle construct, Shimmer uses simpler Atomic Transactions. An Atomic Transaction includes everything related to a transaction in a single message instead of splitting it up (Bundles). This reduces network overhead and signature verification load, improves spam protection and rate control, and shortens the length of Merkle proofs (for future sharding). It also reduces implementation overhead and increases maintainability of the core node software. -- **Application Layer (IOTA 2.0):** The top layer of the 3-layer communication protocol. The IOTA protocol allows a variety of external applications to run on the Message Tangle. Anyone can design an application and users can decide which applications to run on their nodes. These applications will all use the communication layer to transmit and store data. -- **Approval Switch (IOTA 2.0):** When a message is selected as a parent, we can choose from the strong or weak tip pool. This mechanism is called Approval Switch. -- **Approval Weight (IOTA 2.0):** A message gets Mana-weight by approving the message directly or indirectly. However, only strong parents can pass on the mana weight to the past, while weak parents receive the weight from their weak children but do not pass it on. -- **Approvers (IOTA 2.0):** Parents are approved by their referencing messages called approvers. It is thus a reverse mapping of parents. As in the parents’ definition, an approver might be either strong or weak. - -## B - -- **Balance:** Funds on the addresses (account). These are always available and cannot be deleted or forgotten. -- **Blockchain Bottleneck:** The more transactions are issued, the more the block rate and size become a bottleneck in the system. It is no longer possible to capture all incoming transactions in a prompt manner. Attempts to speed up block rates result in more orphaned blocks (blocks are left behind) and reduce the security of the blockchain. -- **Branch (IOTA 2.0):** A version of the ledger that temporarily coexists with other versions, each spawned by conflicting transactions. -- **Bootstrapping attack:** An attack in which a node downloads malicious snapshot files, including invalid transactions and balances. - -## C - -- **Curl:** This is one of the hash functions currently in use. It is based on the “sponge” construction of the Keccak inventors (SHA-3). -- **Confirmed:** Confirmed transactions. In Shimmer, messages in the Tangle are considered for confirmation only when they are directly or indirectly referenced by a milestone that the Coordinator node has validated. To allow the nodes to recognize the milestones, all nodes that participate in the same Shimmer network are configured with the Merkle root address of a Coordinator that they trust to confirm messages. Using this address, nodes can validate the signatures in milestones to verify whether the trusted Coordinator signs them. To make sure that new messages always have a chance of being confirmed, the Coordinator sends indexed milestones at regular intervals. This way, nodes can compare the indexes of their milestones to check whether they are synchronized with the rest of the network. -- **CTPS:** Confirmed transactions per second. -- **Cumulative Weight:** A system for valuing transactions. Each additional transaction that references a transaction increases its cumulative weight. When tips are selected, a path through transactions that has a higher cumulative weight is preferred. -- **Chronicle:** A permanode solution of the IOTA Foundation. It allows to store all transactions reaching a node in a distributed database that is secure and scales well. Chronicle is used to store the Tangle’s unlimited data flow and make it queryable. In other words, permanence allows the entire history of the Tangle to be stored indefinitely and makes that data easily accessible. -- **Consensus:** Agreement on a specific date or value in distributed multi-agent systems, in the presence of faulty processes. -- **Coordinator (only up to IOTA 2.0):** A trusted entity, as protection against malicious transactions. The Tangle is not yet a final product, it is still in beta. The network currently relies on a kind of shield, the so-called coordinator. It is open-source and runs on a Hornet node. The COO acts as a centralized, voluntary, and temporary alternative consensus mechanism for the Tangle. To do this, the COO sends honest transactions to the full nodes at regular intervals. These packets contain a signed message with no value, called a milestone. The full nodes in the Tangle consider a transaction as confirmed only if it is approved by a milestone. Important: The coordinator can only confirm transactions, but he cannot bypass the consensus rules. To create, freeze or steal tokens is not possible for him. This fixed rule and the COO address is hardcoded on each full node, so the coordinator’s influence on the tangle is very limited, since the tangle is also constantly monitored by all the other full nodes. > The Coo will be switched off with the IOTA 2.0 upgrade. -- **Communication Layer (IOTA 2.0):** This layer stores and communicates information. This layer contains the distributed ledger or tangle. The rate control and timestamps are also located in this layer. -- **Core Object type (IOTA 2.0):** An object type that must be parsed by all nodes. Parsers are computer programs responsible for decomposing and converting an input into a format more suitable for further processing. -- **Core Application (IOTA 2.0):** Core application that must be executed by all nodes, for example the value transfer application. -- **Child (IOTA 2.0):** A transaction that gets referenced by Parents. -- **Chrysalis:** The name of the IOTA 1.5 network upgrade. -- **Stardust:** The name of the first Shimmer network upgrade. - -## D - -- **Data:** The tangle is a way of proving the integrity of data (verifiability of completeness and origin) in a trustworthy manner. At present, there are several cryptographic methods that make this possible, but security gaps are repeatedly discovered here, making data vulnerable to manipulation. This is a major problem, especially in cloud computing, where third-party audit tools are sometimes even used (for a fee) to ensure this data integrity. This is exactly where Shimmer comes in and offers a relatively easy way to escape this with its protocol and without fees. -- **Data transactions:** These are confirmed directly and are notarized. With the help of “notarization”, it can be proven that an electronic document existed in a certain form at a certain time and has not been changed since its creation. When a notarization is created, a unique hash (fingerprint) of a document is calculated and stored together with a timestamp in the Shimmer ledger (tangle) in an immutable manner. -- **Data storage:** Just like the internet, the Shimmer protocol does not store data or in other words, the Tangle is not a data storage. If someone wants to store the history of transactions in a decentralized way, they can build a second-layer solution for this themselves or pay third parties for this storage. For the basic layer, Shimmer focuses on performance, throughput, and security rather than building a global database. -- **Distributed Ledger Technology (DLT):** This is a database architecture that allows owners of digital assets to transfer and document them from peer to peer. Each transfer in a DLT is stored as a record in a distributed ledger (database). This database is stored in all nodes of a network. -- **DevNet:** The DevNet (developer network) is a pure test network to research and test a Tangle without Coordinator. -- **Decay:** Both Mana and pending Mana decay proportionally to its value, preventing Mana from growing indefinitely over time. -- **Double-spending:** Double-spending is a threat to a digital money system, where the same single digital token can be spent more than once. Unlike physical money, a digital token consists of a digital file that can be duplicated or counterfeited. -- **dRNG (Decentralized Random Number Generator):** This random number generator is required in Fast Probabilistic Consensus (FPC) to make the consensus model more resilient to attacks. In the case of conflicting transactions, the FPC votes on the transactions in question in several rounds. The threshold at which a node changes its mind in this vote is 50% +/- a small random deviation (using dRNG). In order to avoid stalemate or a specific outcome in the voting, this additional random component prevents potentially malicious nodes from influencing the voting process. -- **Dust Protection (IOTA 1.5):** Someone who wants to harm IOTA could automatically send 1i for years to repeatedly recreated addresses, driving up the ledger’s memory requirements to the point where a full-node would eventually only run on large servers. In Chrysalis if you want to create a microtransaction (<1Mi) you need to activate dust on the receiving address. That will allow you to receive a certain amount of dust. Also, the addresses with Colored Coins have to be tokenized. After the Coordicide, there will be another solution for IOTA 2.0. -- **Directed Acyclic Graph (DAG):** A directed acyclic graph is DLT structure that consists of edges and vertices that never form a closed loop. The Shimmer architecture "the Tangle" is a form of directed acyclic graph. - -## E - -- **Eclipse attack:** A cyber-attack that aims to isolate a specific node rather than attack the entire network. -- **ETH Virtual Machine:** A VM is what executes the Smart Contract code so that it runs deterministically. The language in which you run the code provides hooks to access the sandbox on which the VM runs. In the case of Shimmer, this is the ISC sandbox, which only provides access to Shimmer tokens, thus consensus also runs on Shimmer tokens. It is only the VM that Shimmer works with, foreign tokens have nothing to do with a VM running the SC code, not the ETH VM, nor the Cartesi VM. -- **Epoch (IOTA 2.0):** A time interval used for a specific type of consensus mana. At the end of each epoch, a snapshot is taken of the state of mana distribution on the network. Since this tool uses the timestamp of messages, each node can eventually reach a consensus on the mana distribution of an epoch. - -## F - -- **Faucet:** A pool of tokens (funds). Upon uncomplicated request, one gets a limited number of tokens for testing, especially for developers of own apps this is a great help. -- **Firefly:** Firefly is a wallet, intended to serve as a platform for the current and future Shimmer ecosystem. -- **Finality:** The property that once a transaction has been completed, there is no way to reverse or change it. This is the moment when the parties involved in a transfer can consider the transaction completed. Finality can be deterministic or probabilistic. -- **Full nodes (Hornet):** They form the core (infrastructure) of the Shimmer network. In order to participate in the peer-to-peer network, the full node must always be online and connected to neighbors (other full nodes). In addition, the transaction database must be synchronized with all other full nodes in the network. The role of full nodes is to interact with clients (wallets, DApps, etc.) and attach their transactions to the ledger, make transactions known to all other full nodes in the network, validate transactions and store them in the ledger. -- **Future Cone:** All messages that directly or indirectly reference a message are called its future cone. -- **Fork:** In IT, this is a new development branch after a project is split into a second follow-on project; the source code or parts of it are developed independently of the original parent project. -- **FPC(Fast Probabilistic Consensus):** Consensus that uses a random number and node opinions to reach consensus. In On-Tangle Voting, it is only used in a specific edge case. Check out OTVFPCS. - -## G - -- **Genesis transaction:** The Genesis transaction is the first transaction that created all Shimmer tokens and distributed them to the addresses of the buyers. -- **GoShimmer (No Main net):** Prototype of the coordinator less version of IOTA written in the Go programming language. GoShimmer implements the various modules of Coordicide, such as auto peering, node identities, Mana, etc. GoShimmer serves as a test environment for the first alpha version and the test network. Everything tested here will be gradually merged with Hornet. -- **Generic Data Object (IOTA 2.0):** The most basic object type. All unrecognized data objects are defined this way. - -## H - -- **History:** The list of transactions that were directly or indirectly authorized by a particular transaction. -- **Hash values:** Checksums that are applied to the encryption of messages of variable length. Hash values are like fingerprints of a very long data set. Each message is assigned a very specific hash value. -- **Hooks:** An interface that allows foreign program code to be integrated into an existing application to extend it, change its flow, or intercept certain events. -- **Hornet Node:** Shimmer Node written in the Go programming language. In addition, the coordinator also runs as a plugin via Hornet. - -## I - -- **Inclusion state:** Used to determine if a transaction has been accepted and confirmed by the network. Especially for a transaction and a list of tips: Inclusion state is true if the tip refers to this transaction. - -## L - -- **Local Snapshots:** Local snapshots are used to limit the memory requirements of the nodes. For this purpose, on the individual nodes old, already confirmed, transactions are deleted from the database. What remains is only a small file (list) with the balances on the respective addresses. Nodes perform the snapshot independently and at their own discretion. This feature allows faster synchronization, lower system resource requirements and no more waiting for global snapshots to clean up the database. -- **Layer:** In DLT a 2nd-layer refers to a secondary framework or protocol built on top of an existing distributed ledger. On these second layers, other applications can be executed without putting too much strain on the base layer. In Shimmer, for example, these are the Smart Contracts. -- **Local Modifiers:** User-defined conditions that can be considered by nodes during tip selection. In Shimmer, nodes do not necessarily have the same view of the tangle. Different types of information that are only available to them locally can be used to strengthen security. - -## M - -- **Merkle Tree:** A Merkle tree is a data structure used in computer science applications. In cryptocurrencies, Merkle trees are used to encode more efficiently and securely. -- **Mainnet:** The public usable IOTA network, in which the IOTA tokens are used that are traded on cryptocurrency exchanges. -- **Milestone (IOTA 1.5):** Milestones are messages that are signed and issued by the coordinator. Their main goal is to help the Tangle grow healthily and guarantee finality. When milestones directly or indirectly approve a transaction in the Tangle, nodes mark the status of that transaction and its entire history as confirmed. -- **Message:** A message is a core data type that reflects a vertex in the communication layer DAG. It contains the following properties: References to other messages, the sender’s public key, the issuing time of the message, the message sequence number from the node that issued the message, the payload that can be interpreted by higher layers, the nonce that the message uses to satisfy the PoW requirement, a signature that signs all of the above fields. A message is not forwarded until it becomes “solid”, i.e., its history is known to the node. Messages must meet a PoW requirement, which currently is to find a nonce so that the hash of the message’s fields (minus the signature) has a certain number of leading zeros. -- **Message overhead:** The additional information (metadata) that must be sent along with the actual information (data). This can include signatures, polls and anything that is transmitted over the network but is not the transaction itself. -- **Mana (IOTA 2.0):** When a value transaction is processed, a quantity called Mana will be “pledged” to a specified node ID. This quantity is related to the amount of IOTA moved into the transaction. The only way to gain Mana is to convince some token holder to pledge it to you. In this sense, Mana is Delegated Proof of Token Ownership. Mana, therefore, provides adequate Sybil protection because it is difficult to acquire it in arbitrary amounts. -- **Markers (IOTA 2.0):** A tool that exists only locally and allows certain calculations to be performed more efficiently, such as the calculation of the approval weight or the presence of certain messages in the past or future cone of another message. -- **Messages per Second (MPS):** The amount of messages issued to the network every second. - -## N - -- **Nakamoto Consensus:** Named after the creator of Bitcoin, Satoshi Nakamoto, the Nakamoto Consensus describes the replacement of coordination / communication between known agents with a cryptographic puzzle (Proof-of-Work). Completion of the puzzle determines which agent acts next. -- **Neighbors:** Network nodes that are directly connected and can exchange messages without intermediate nodes. -- **Nodes:** A node is any computer that connects to other nodes in the network via software. In principle, they serve as a connection point for data transfers. The Tangle works with different types of nodes, such as full nodes like Hornet, permanodes (Chronicle) or smart contract nodes (Wasp). -- **Network Layer (IOTA 2.0):** This layer manages the lower layers of Internet communication such as TCP. In this layer, the connections between the nodes are managed by the Auto peering and Peer Discovery modules and the Gossip protocol. -- **Network ID:** The network ID enables user-specific subtangles in which nodes can only recognize messages from the network ID listed in their configuration file. - -## O - -- **Orphan:** A transaction (or block) that is not referenced by any subsequent transaction (or block). An orphan is not considered confirmed and will not be part of the consensus. -- **Object (IOTA 2.0):** the most basic unit of information in the IOTA protocol. Each object has a type and size and contains data. -- **Oracles:** Oracles are designed to build a secure bridge between the digital and physical worlds in a decentralized, permissionless way. They bring off-chain data to decentralized applications and smart contracts on the Shimmer network. -- **OTV (IOTA 2.0):** On Tangle Voting is the official name for the multiverse consensus described by Hans Moog. It is a new consensus mechanism that allows nodes to vote on conflicts directly by publishing a message to the tangle. -- **OTVFPCS (IOTA 2.0):** On Tangle Voting with FPCS (Fast Probabilistic Consensus on a Set) is a mechanism for breaking metastability, which can be used in addition to OTV (On Tangle Voting). Generally, in IOTA2.0, reaching a high approval weight is the finality criteria. If the approval weight is high enough, the message / transaction is finalized. With OTVFPC the initial opinion is created with OTV, if after some time the opinions of the nodes are still split, for whatever reason, FPC is activated to break this metastable state. The finality of value transactions should be reached faster this way. - -## P - -- **Parents:** A message directly references up to 8 previous messages that we call its parents. In IOTA 2.0 a parent can be either strong or weak (see approval switch). -- **Parallel reality ledger state (IOTA 2.0):** This state is used to track conflicts in the tangle. Two new ledger entries that are causally valid but in conflict with each other (ex. Double Spend) are posted into two separate “realities” for this purpose, representing possible but mutually exclusive future ledger states. The consensus mechanism (with FPC, etc.) will now operate until the perception of most nodes tilts in one direction and one of the two possible ledger states is accepted as true. -- **Partition Tolerant:** This means that a part of the Tangle can be disconnected from the main tangle for a certain time and continue to run without an Internet connection. These parts can be reconnected to the main Tangle when the Internet connection is restored. -- **Past Cone:** All messages that are directly or indirectly referenced by a message are called its past cone. -- **Parasite Chain Attacks:** A double spending attack on the Tangle. Here, an attacker attempts to reverse a transaction by setting up an alternate Tangle in which the funds were not spent. He then tries to get the majority of the network to accept the alternative Tangle as the legitimate one. -- **Permanode:** This type of node permanently stores the entire transaction history, possibly with the help of external storage solutions, and possibly only specific transactions (selective permanode). -- **Pending:** A transaction has been seen by the network but not yet confirmed. -- **Peer to Peer Network:** A decentralized network of different network nodes that are connected to each other and exchange data. -- **Peering:** The process of discovering and connecting to other network nodes. -- **Payload (IOTA 2.0):** A field in a message that determines the type. Examples are value payload (TransactionType type), FPC opinion payload (StatementType type), dRNG payload (Payload), Salt declaration payload, generic data payload. -- **Private Tangle:** A private tangle is comparable to a test network under complete control of the operator. This allows companies and developers to test their applications under self-defined environment variables without external influences and protected from prying eyes. There is no interoperability between a private Tangle and the Shimmer Tangle. So, sending from one to the other does not work either. Each private Tangle is an independent network with its own nodes, tokens, and coordinator. -- **Proof of Work (PoW):** A time-consuming (expensive) mathematical calculation that uses computational power to prevent spam attacks. It consists of a difficult cryptographic puzzle that is easy to verify. -- **Proof of Inclusion (PoI):** With PoI, one is able to provide evidence that a transaction was indirectly referenced by another transaction without having to present the full chain of actual transactions between the two transactions. This is done by using a sequence of hashes instead of the actual transaction data to prove the inclusion of a transaction (inclusion) in the referenced subtangle. -- **Pruning:** In computer science, this is a term for simplifying, shortening, and optimizing decision trees. In Shimmer, this is done by local snapshots on each full node. Old transactions that have already been confirmed are deleted from the database, leaving only a file (list) of credits on each address. -- **Public and private keys:** These are used in cryptographic systems which use key pairs. There are public keys which can be shared and private keys which are known only to the owner. The generation of such keys depends on cryptographic algorithms based on mathematical problems to generate one-way functions. Effective security requires keeping the private key to remain only known to the owner. Public keys derived from this private key can be shared and used by others to verify ownership of the private key, without exposing the private key. Public keys function as addresses in Shimmer. - -## R - -- **Rebroadcast:** Repeats the sending of a transaction. While a transaction is being sent to an Shimmer node, it may go offline. In this case, the Shimmer node may not forward the transactions to its neighbors, and the rest of the network will never see these transactions. As a result, that transaction will never be referenced by the coordinator and thus never confirmed. Resending a bundle means resending the same bundle to an Shimmer node. This way you give your transactions another chance to be forwarded to the rest of the network. -- **Reusable Addresses:** With the introduction of the Ed25519 signature scheme, through the IOTA 1.5 Chrysalis upgrade, reusable addresses are now supported. -- **Reattachment:** Resending a transaction by re-selecting a tip and referencing newer tips by repeating PoW. - -## S - -- **Salt:** In cryptography, salt is a randomly chosen string of characters that is appended to a given plaintext before it is further processed to increase the entropy (disorder) of the input. It is often used for storing and transmitting passwords to increase information security. -- **Sandbox:** An isolated area where programs can be tested. -- **Software as a Service (SaaS):** The SaaS model is a subset of cloud computing. It is based on the principle that the software and IT infrastructure can be operated by an external service provider and rented by the customer as a service. -- **Smart Contract:** Smart contracts are contracts or programs that are automatically executed. -- **Smart Contract Chain:** Smart contracts are processed via a so-called contract chain, the representation of the contract state. A smart contract writes its state every time it is requested, and a new block is added for each of these state updates. All these updates are collected and confirmed in one block. So, the chain also contains all the past states. The chain can contain many Smart Contracts, all working on the same global state of the chain. From this perspective, the Contract chain is essentially a blockchain anchored on the Tangle. IOTA Smart Contracts can be considered “classic” Smart Contracts, but with the added feature that you can have multiple such parallel chains all using the same native Shimmer token and trading between them in a trusted manner on the Tangle. This enables trusted interoperability between different applications. -- **Solidification time:** The time of solidification when the entire history of a transaction has been received by a node. -- **Splitting Attacks:** An attack in which a malicious node attempts to split the tangle into two branches. As one of the branches grows, the attacker publishes transactions on the other branch to keep both alive. Splitting attacks attempt to slow down the consensus process or perform double spending. -- **Sharding:** Shimmer nodes have an upper limit on transactions per second (TPS) they can process. Through a type of database partitioning (breaking a very large database into smaller ones) into more manageable segments (shards), each shard would contain a unique set of account balances and nodes would then be assigned to individual shards to validate transactions. The goal is that by dividing into more manageable segments, it will increase transaction throughput and thus overcome scalability issues. -- **Signatures:** Signatures prove ownership of an address. Clients (Wallets) need this proof before nodes validate a transaction. To prove ownership, input transactions must be signed with the private key used to create the address. -- **Solidity (IOTA 2.0):** A message is marked as solid if its entire past cone until the Genesis (or the latest snapshot) is known. -- **Subtangle:** A consistent section of the tangle (i.e., a subset of messages / value objects) such that each contained message / value object also contains its referenced messages / value objects. -- **Streams:** IOTA Streams is a multifunctional second layer data transfer protocol that can be used for various types of data transfer (e.g., streaming data). For example, it allows sensors and other devices to encrypt entire data streams and anchor them in the IOTA Tangle. IOTA’s consensus protocol adds integrity and authenticity to these message streams. Given these characteristics, IOTA Streams fills an important need in industries where integrity, privacy, and immutability collide. -- **Sybil Attack:** An attempt to gain control of a peer-to-peer network by forging multiple false identities. -- **Snapshot:** A special feature of the Tangle. A snapshot deletes all transactions. Only transactions with a balance > 0 are kept. The metadata such as tags and messages are also deleted. What is left behind is just a list of addresses and balances. After a snapshot, the nodes use this list as “genesis”, a new starting point for the tangle. This reduces the size of the tangle network, allowing Shimmer nodes to use less memory. Full nodes perform what are called “Local Snapshots” independently and at their own discretion. - -## T - -- **Tangle:** The Tangle is the underlying core data structure. In mathematical terms it is a directed acyclic graph (DAG). The Tangle is the distributed ledger of Shimmer that stores all transactions. -- **Ternary system:** A trit (trinary digit) can have exactly three states (3 x 1 = 3): -1, 0 and 1. Three trits result in one tryte (33 = 27) and can thus represent 27 combinations. In IOTA, the letters A-Z (26 pieces) and the number 9 are used for this purpose. -- **Token:** The digital currency form (cryptocurrency). It is a powerful tool for value transfer between people and machines. Total number: 2,779,530,283,277,761 IOTA. The base units are Pi, Ti, Gi, Mi, ki, i -- **Trinity (IOTA 1.0):** Depreciated IOTA Wallet -- **Tip:** A transaction that has not yet been approved. -- **Tip Selection:** The process of selecting previous transactions to be referenced by a new transaction. In these references, a transaction ties into the existing data structure. Shimmer only enforces that a transaction approves up to eight other transactions, the tip selection strategy is left to the user (with a good default provided by Shimmer). -- **Tip Transaction:** A solid end transaction that is not yet a parent. -- **Transaction (IOTA 2.0):** A message that contains a Token transfer as a payload. The transferred tokens can be native IOTA Tokens or native IOTA Assets. - -## U - -- **UTXO model:** This is a so-called addressing model. UTXO stands for “unspent transaction output”, which simply means that you not only keep track of the credits on the address, but also keep track of where the credits come from and where they are sent when they are spent. Each token on an address is thus uniquely identifiable and each issue names the exact token they want to move. This enables faster and more accurate conflict handling and improves the resilience and security of the protocol. - -## V - -- **Value Layer (IOTA 2.0):** The Value layer builds on the Communication layer. It works exclusively with payloads of type Value object. This layer has several tasks: Forming the ledger state, processing, validation and output of transactions, conflict detection, conflict resolution via FPC, forming a DAG from value objects, tip selection (on value object tips). -- **Value Transactions:** Value transactions either withdraw Shimmer tokens from an address or deposit them to an address. Nodes must verify these transactions to ensure that the sender actually owns the Shimmer tokens and that additional tokens are never generated. To do this, the following checks are performed: All Shimmer tokens withdrawn from an address are also deposited into one or more other addresses; the value of each transaction does not exceed the total global supply; signatures are valid. -- **Version Number (IOTA 2.0):** Indicates the correct format of each type. - -## W - -- **White-flag approach (IOTA 1.5):** Used to calculate credits. A simpler, conflict-avoiding approach that improves the speed and efficiency of tip selection, eliminates certain attacks, and significantly reduces the need for reattachments. -- **Wasp:** The Wasp node software is an implementation of Smart Contracts on the Shimmer Tangle. diff --git a/next/learn/glossary.mdx b/next/learn/glossary.mdx new file mode 100644 index 00000000000..6686ebb7b0f --- /dev/null +++ b/next/learn/glossary.mdx @@ -0,0 +1,8 @@ +--- +title: Glossary +description: Glossary of all specialized names and phrases used in the IOTA and Shimmer networks. If you dont understand a wording you will find answers here. +--- + +import Glossary from '@theme/Glossary'; + + diff --git a/shimmer/docusaurus.config.js b/shimmer/docusaurus.config.js index d94cf557786..565ec89f84b 100644 --- a/shimmer/docusaurus.config.js +++ b/shimmer/docusaurus.config.js @@ -8,7 +8,7 @@ module.exports = async () => { async (contentConfig) => await create_doc_plugin(contentConfig), ), ); - //console.log(contentPlugins); + const staticDirs = await globStatic('/docs/**/static/', __dirname); return { diff --git a/shimmer/learn/data-and-value-transfer.md b/shimmer/learn/data-and-value-transfer.md index 49d9d38e403..bcdfd89cc88 100644 --- a/shimmer/learn/data-and-value-transfer.md +++ b/shimmer/learn/data-and-value-transfer.md @@ -37,7 +37,7 @@ The node selects these blocks by using an algorithm called **Uniform Random Tip :::tip Send Data -The Stardust protocol allows you to attach [metadata](outputs.md#metadata) to any transaction. +The _Stardust_ protocol allows you to attach [metadata](outputs.md#metadata) to any transaction. ::: From 50feb46140a6fe6381b9ab9c2cec32e16bf7660a Mon Sep 17 00:00:00 2001 From: Dr-Electron Date: Mon, 10 Jul 2023 22:12:39 +0200 Subject: [PATCH 5/8] Format --- iota/docusaurus.config.js | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/iota/docusaurus.config.js b/iota/docusaurus.config.js index 40397a44cd8..0a48b5dc3e3 100644 --- a/iota/docusaurus.config.js +++ b/iota/docusaurus.config.js @@ -4,9 +4,9 @@ const { create_doc_plugin, globStatic } = require('../src/utils/config'); module.exports = async () => { const contentPlugins = await Promise.all( - (await contentConfigs()).map( - async (contentConfig) => await create_doc_plugin(contentConfig), - ), + ( + await contentConfigs() + ).map(async (contentConfig) => await create_doc_plugin(contentConfig)), ); const staticDirs = await globStatic('/docs/**/static/', __dirname); From a9809eba20c7344756bc746b38c060e030146dcc Mon Sep 17 00:00:00 2001 From: Lucas Tortora Date: Mon, 17 Jul 2023 08:50:50 -0300 Subject: [PATCH 6/8] minor edits format --- common/jargon.js | 104 +++++++++++++++++++++++------------------------ 1 file changed, 51 insertions(+), 53 deletions(-) diff --git a/common/jargon.js b/common/jargon.js index 14adc9ef740..401c10f3ddf 100644 --- a/common/jargon.js +++ b/common/jargon.js @@ -5,25 +5,25 @@ module.exports = { '(In development for IOTA 1.5 and Shimmer): With this feature, the coordinator can issue a milestone and simultaneously set the future PoW score. This means that if the network is not fully utilized, the PoW will be reduced to the point where it can be executed by microdevices. Accordingly, the coordinator can also raise the PoW difficulty in case of high utilization and thus make an attack very expensive.', 'auto peering': 'A mechanism that allows nodes to automatically select their neighbors without manual intervention by the node operator.', - 'api(application programming interfaces)': + 'API(application programming interfaces)': 'The way for applications to interact with the Tangle.', 'atomic transactions': 'Instead of the bundle construct, IOTA and Shimmer use simpler Atomic Transactions. An Atomic Transaction includes everything related to a transaction in a single message instead of splitting it up (Bundles). This reduces network overhead and signature verification load, improves spam protection and rate control, and shortens the length of Merkle proofs (for future sharding). It also reduces implementation overhead and increases maintainability of the core node software.', - 'application layer (iota 2.0)': - 'The top layer of the 3-layer communication protocol. The IOTA protocol allows a variety of external applications to run on the Message Tangle. Anyone can design an application and users can decide which applications to run on their nodes. These applications will all use the communication layer to transmit and store data.', - 'approval switch (iota 2.0)': - 'When a message is selected as a parent, we can choose from the strong or weak tip pool. This mechanism is called Approval Switch.', - 'approval weight (iota 2.0)': - 'A message gets Mana-weight by approving the message directly or indirectly. However, only strong parents can pass on the mana weight to the past, while weak parents receive the weight from their weak children but do not pass it on.', - 'approvers (iota 2.0)': - 'Parents are approved by their referencing messages called approvers. It is thus a reverse mapping of parents. As in the parents definition, an approver might be either strong or weak.', + 'application layer': + '(iota 2.0) The top layer of the 3-layer communication protocol. The IOTA protocol allows a variety of external applications to run on the Message Tangle. Anyone can design an application and users can decide which applications to run on their nodes. These applications will all use the communication layer to transmit and store data.', + 'approval switch': + '(iota 2.0) When a message is selected as a parent, we can choose from the strong or weak tip pool. This mechanism is called Approval Switch.', + 'approval weight': + '(iota 2.0) A message gets Mana-weight by approving the message directly or indirectly. However, only strong parents can pass on the mana weight to the past, while weak parents receive the weight from their weak children but do not pass it on.', + approvers: + '(iota 2.0)Parents are approved by their referencing messages called approvers. It is thus a reverse mapping of parents. As in the parents definition, an approver might be either strong or weak.', balance: 'Funds on the addresses (account). These are always available and cannot be deleted or forgotten.', 'blockchain bottleneck': 'The more transactions are issued, the more the block rate and size become a bottleneck in the system. It is no longer possible to capture all incoming transactions in a prompt manner. Attempts to speed up block rates result in more orphaned blocks (blocks are left behind) and reduce the security of the blockchain.', - 'branch (iota 2.0)': - 'A version of the ledger that temporarily coexists with other versions, each spawned by conflicting transactions.', - bee: 'Node software developed by the IOTA foundation using the Rust programming language.', + branch: + '(iota 2.0) A version of the ledger that temporarily coexists with other versions, each spawned by conflicting transactions.', + bee: '(Deprecated) Node software developed by the IOTA foundation using the Rust programming language.', 'bootstrapping attack': 'An attack in which a node downloads malicious snapshot files, including invalid transactions and balances.', curl: 'This is one of the hash functions currently in use. It is based on the "sponge" construction of the Keccak inventors (SHA-3).', @@ -38,13 +38,13 @@ module.exports = { 'Agreement on a specific date or value in distributed multi-agent systems, in the presence of faulty processes.', 'coordinator (only up to iota 2.0)': 'A trusted entity, as protection against malicious transactions. The Tangle is not yet a final product, it is still in beta. The network currently relies on a kind of shield, the so-called coordinator. It is open-source and runs on a Hornet node. The COO acts as a centralized, voluntary, and temporary alternative consensus mechanism for the Tangle. To do this, the COO sends honest transactions to the full nodes at regular intervals. These packets contain a signed message with no value, called a milestone. The full nodes in the Tangle consider a transaction as confirmed only if it is approved by a milestone. Important: The coordinator can only confirm transactions, but he cannot bypass the consensus rules. To create, freeze or steal tokens is not possible for him. This fixed rule and the COO address is hardcoded on each full node, so the coordinator\u2019s influence on the tangle is very limited, since the tangle is also constantly monitored by all the other full nodes. > The Coo will be switched off with the IOTA 2.0 upgrade.', - 'communication layer (iota 2.0)': - 'This layer stores and communicates information. This layer contains the distributed ledger or tangle. The rate control and timestamps are also located in this layer.', - 'core object type (iota 2.0)': - 'An object type that must be parsed by all nodes. Parsers are computer programs responsible for decomposing and converting an input into a format more suitable for further processing.', - 'core application (iota 2.0)': - 'Core application that must be executed by all nodes, for example the value transfer application.', - 'child (iota 2.0)': 'A transaction that gets referenced by Parents.', + 'communication layer': + '(iota 2.0) This layer stores and communicates information. This layer contains the distributed ledger or tangle. The rate control and timestamps are also located in this layer.', + 'core object type': + '(iota 2.0) An object type that must be parsed by all nodes. Parsers are computer programs responsible for decomposing and converting an input into a format more suitable for further processing.', + 'core application': + '(iota 2.0) Core application that must be executed by all nodes, for example the value transfer application.', + child: '(iota 2.0) A transaction that gets referenced by Parents.', chrysalis: 'The name of the IOTA 1.5 network upgrade.', stardust: 'The name of the first Shimmer network upgrade.', data: 'The tangle is a way of proving the integrity of data (verifiability of completeness and origin) in a trustworthy manner. At present, there are several cryptographic methods that make this possible, but security gaps are repeatedly discovered here, making data vulnerable to manipulation. This is a major problem, especially in cloud computing, where third-party audit tools are sometimes even used (for a fee) to ensure this data integrity. This is exactly where IOTA and Shimmer come in and offers a relatively easy way to escape this with its protocol and without fees.', @@ -62,16 +62,16 @@ module.exports = { 'Double-spending is a threat to a digital money system, where the same single digital token can be spent more than once. Unlike physical money, a digital token consists of a digital file that can be duplicated or counterfeited.', 'drng (decentralized random number generator)': 'This random number generator is required in Fast Probabilistic Consensus (FPC) to make the consensus model more resilient to attacks. In the case of conflicting transactions, the FPC votes on the transactions in question in several rounds. The threshold at which a node changes its mind in this vote is 50% +/- a small random deviation (using dRNG). In order to avoid stalemate or a specific outcome in the voting, this additional random component prevents potentially malicious nodes from influencing the voting process.', - 'dust protection (iota 1.5)': - 'Someone who wants to harm IOTA could automatically send 1i for years to repeatedly recreated addresses, driving up the ledger\u2019s memory requirements to the point where a full-node would eventually only run on large servers. In Chrysalis if you want to create a microtransaction (<1Mi) you need to activate dust on the receiving address. That will allow you to receive a certain amount of dust. Also, the addresses with Colored Coins have to be tokenized. After the Coordicide, there will be another solution for IOTA 2.0.', + 'dust protection': + '(iota 1.5) Someone who wants to harm IOTA could automatically send 1i for years to repeatedly recreated addresses, driving up the ledger\u2019s memory requirements to the point where a full-node would eventually only run on large servers. In Chrysalis if you want to create a microtransaction (<1Mi) you need to activate dust on the receiving address. That will allow you to receive a certain amount of dust. Also, the addresses with Colored Coins have to be tokenized. After the Coordicide, there will be another solution for IOTA 2.0.', 'directed acyclic graph (dag)': 'A directed acyclic graph is DLT structure that consists of edges and vertices that never form a closed loop. The Tangle is a form of directed acyclic graph.', 'eclipse attack': 'A cyber-attack that aims to isolate a specific node rather than attack the entire network.', 'eth virtual machine': 'A VM is what executes the Smart Contract code so that it runs deterministically. The language in which you run the code provides hooks to access the sandbox on which the VM runs. In the case of Shimmer, this is the ISC sandbox, which only provides access to Shimmer tokens, thus consensus also runs on Shimmer tokens. It is only the VM that Shimmer works with, foreign tokens have nothing to do with a VM running the SC code, not the ETH VM, nor the Cartesi VM.', - 'epoch (iota 2.0)': - 'A time interval used for a specific type of consensus mana. At the end of each epoch, a snapshot is taken of the state of mana distribution on the network. Since this tool uses the timestamp of messages, each node can eventually reach a consensus on the mana distribution of an epoch.', + epoch: + '(iota 2.0) A time interval used for a specific type of consensus mana. At the end of each epoch, a snapshot is taken of the state of mana distribution on the network. Since this tool uses the timestamp of messages, each node can eventually reach a consensus on the mana distribution of an epoch.', faucet: 'A pool of tokens (funds). Upon uncomplicated request, one gets a limited number of tokens for testing, especially for developers of own apps this is a great help.', firefly: @@ -89,15 +89,15 @@ module.exports = { 'The Genesis transaction is the first transaction that created all IOTA and Shimmer tokens and distributed them to the addresses of the buyers.', 'goshimmer (no main net)': 'Prototype of the coordinator less version of IOTA written in the Go programming language. GoShimmer implements the various modules of Coordicide, such as auto peering, node identities, Mana, etc. GoShimmer serves as a test environment for the first alpha version and the test network. Everything tested here will be gradually merged with Hornet and Bee.', - 'generic data object (iota 2.0)': - 'The most basic object type. All unrecognized data objects are defined this way.', + 'generic data object': + '(iota 2.0) The most basic object type. All unrecognized data objects are defined this way.', history: 'The list of transactions that were directly or indirectly authorized by a particular transaction.', 'hash values': 'Checksums that are applied to the encryption of messages of variable length. Hash values are like fingerprints of a very long data set. Each message is assigned a very specific hash value.', hooks: 'An interface that allows foreign program code to be integrated into an existing application to extend it, change its flow, or intercept certain events.', - 'hornet node (iota 1.5)': + 'hornet node': 'Community-developed IOTA Node written in the Go programming language. In addition, the coordinator also runs as a plugin via Hornet.', 'hornet node (shimmer)': 'Shimmer Node written in the Go programming language. In addition, the coordinator also runs as a plugin via Hornet.', @@ -113,16 +113,15 @@ module.exports = { 'A Merkle tree is a data structure used in computer science applications. In cryptocurrencies, Merkle trees are used to encode more efficiently and securely.', mainnet: 'The public usable IOTA network, in which the IOTA tokens are used that are traded on cryptocurrency exchanges.', - 'milestone (iota 1.5)': - 'Milestones are messages that are signed and issued by the coordinator. Their main goal is to help the Tangle grow healthily and guarantee finality. When milestones directly or indirectly approve a transaction in the Tangle, nodes mark the status of that transaction and its entire history as confirmed.', + milestone: + '(iota 1.5) Milestones are messages that are signed and issued by the coordinator. Their main goal is to help the Tangle grow healthily and guarantee finality. When milestones directly or indirectly approve a transaction in the Tangle, nodes mark the status of that transaction and its entire history as confirmed.', message: 'A message is a core data type that reflects a vertex in the communication layer DAG. It contains the following properties: References to other messages, the sender\u2019s public key, the issuing time of the message, the message sequence number from the node that issued the message, the payload that can be interpreted by higher layers, the nonce that the message uses to satisfy the PoW requirement, a signature that signs all of the above fields. A message is not forwarded until it becomes "solid", i.e., its history is known to the node. Messages must meet a PoW requirement, which currently is to find a nonce so that the hash of the message\u2019s fields (minus the signature) has a certain number of leading zeros.', 'message overhead': 'The additional information (metadata) that must be sent along with the actual information (data). This can include signatures, polls and anything that is transmitted over the network but is not the transaction itself.', - 'mana (iota 2.0)': - 'When a value transaction is processed, a quantity called Mana will be "pledged" to a specified node ID. This quantity is related to the amount of IOTA moved into the transaction. The only way to gain Mana is to convince some token holder to pledge it to you. In this sense, Mana is Delegated Proof of Token Ownership. Mana, therefore, provides adequate Sybil protection because it is difficult to acquire it in arbitrary amounts.', - 'markers (iota 2.0)': - 'A tool that exists only locally and allows certain calculations to be performed more efficiently, such as the calculation of the approval weight or the presence of certain messages in the past or future cone of another message.', + mana: ' (iota 2.0) When a value transaction is processed, a quantity called Mana will be "pledged" to a specified node ID. This quantity is related to the amount of IOTA moved into the transaction. The only way to gain Mana is to convince some token holder to pledge it to you. In this sense, Mana is Delegated Proof of Token Ownership. Mana, therefore, provides adequate Sybil protection because it is difficult to acquire it in arbitrary amounts.', + markers: + '(iota 2.0) A tool that exists only locally and allows certain calculations to be performed more efficiently, such as the calculation of the approval weight or the presence of certain messages in the past or future cone of another message.', 'messages per second (mps)': 'The amount of messages issued to the network every second.', 'nakamoto consensus': @@ -131,24 +130,23 @@ module.exports = { 'Network nodes that are directly connected and can exchange messages without intermediate nodes.', nodes: 'A node is any computer that connects to other nodes in the network via software. In principle, they serve as a connection point for data transfers. The Tangle works with different types of nodes, such as full nodes (Hornet, Bee), permanodes (Chronicle) or smart contract nodes (Wasp).', - 'network layer (iota 2.0)': - 'This layer manages the lower layers of Internet communication such as TCP. In this layer, the connections between the nodes are managed by the Auto peering and Peer Discovery modules and the Gossip protocol.', + 'network layer': + '(iota 2.0) This layer manages the lower layers of Internet communication such as TCP. In this layer, the connections between the nodes are managed by the Auto peering and Peer Discovery modules and the Gossip protocol.', 'network id': 'The network ID enables user-specific subtangles in which nodes can only recognize messages from the network ID listed in their configuration file.', orphan: 'A transaction (or block) that is not referenced by any subsequent transaction (or block). An orphan is not considered confirmed and will not be part of the consensus.', - 'object (iota 2.0)': - 'the most basic unit of information in the IOTA protocol. Each object has a type and size and contains data.', + object: + ' (iota 2.0) The most basic unit of information in the IOTA protocol. Each object has a type and size and contains data.', oracles: 'Oracles are designed to build a secure bridge between the digital and physical worlds in a decentralized, permissionless way. They bring off-chain data to decentralized applications and smart contracts on the network.', - 'otv (iota 2.0)': - 'On Tangle Voting is the official name for the multiverse consensus described by Hans Moog. It is a new consensus mechanism that allows nodes to vote on conflicts directly by publishing a message to the tangle.', - 'otvfpcs (iota 2.0)': - 'On Tangle Voting with FPCS (Fast Probabilistic Consensus on a Set) is a mechanism for breaking metastability, which can be used in addition to OTV (On Tangle Voting). Generally, in IOTA2.0, reaching a high approval weight is the finality criteria. If the approval weight is high enough, the message / transaction is finalized. With OTVFPC the initial opinion is created with OTV, if after some time the opinions of the nodes are still split, for whatever reason, FPC is activated to break this metastable state. The finality of value transactions should be reached faster this way.', + otv: '(iota 2.0) On Tangle Voting is the official name for the multiverse consensus described by Hans Moog. It is a new consensus mechanism that allows nodes to vote on conflicts directly by publishing a message to the tangle.', + otvfpcs: + '(iota 2.0) On Tangle Voting with FPCS (Fast Probabilistic Consensus on a Set) is a mechanism for breaking metastability, which can be used in addition to OTV (On Tangle Voting). Generally, in IOTA2.0, reaching a high approval weight is the finality criteria. If the approval weight is high enough, the message / transaction is finalized. With OTVFPC the initial opinion is created with OTV, if after some time the opinions of the nodes are still split, for whatever reason, FPC is activated to break this metastable state. The finality of value transactions should be reached faster this way.', parents: 'A message directly references up to 8 previous messages that we call its parents. In IOTA 2.0 a parent can be either strong or weak (see approval switch).', - 'parallel reality ledger state (iota 2.0)': - 'This state is used to track conflicts in the tangle. Two new ledger entries that are causally valid but in conflict with each other (ex. Double Spend) are posted into two separate "realities" for this purpose, representing possible but mutually exclusive future ledger states. The consensus mechanism (with FPC, etc.) will now operate until the perception of most nodes tilts in one direction and one of the two possible ledger states is accepted as true.', + 'parallel reality ledger state': + '(iota 2.0) This state is used to track conflicts in the tangle. Two new ledger entries that are causally valid but in conflict with each other (ex. Double Spend) are posted into two separate "realities" for this purpose, representing possible but mutually exclusive future ledger states. The consensus mechanism (with FPC, etc.) will now operate until the perception of most nodes tilts in one direction and one of the two possible ledger states is accepted as true.', 'partition tolerant': 'This means that a part of the Tangle can be disconnected from the main tangle for a certain time and continue to run without an Internet connection. These parts can be reconnected to the main Tangle when the Internet connection is restored.', 'past cone': @@ -161,8 +159,8 @@ module.exports = { 'peer to peer network': 'A decentralized network of different network nodes that are connected to each other and exchange data.', peering: 'The process of discovering and connecting to other network nodes.', - 'payload (iota 2.0)': - 'A field in a message that determines the type. Examples are value payload (TransactionType type), FPC opinion payload (StatementType type), dRNG payload (Payload), Salt declaration payload, generic data payload.', + payload: + '(iota 2.0)A field in a message that determines the type. Examples are value payload (TransactionType type), FPC opinion payload (StatementType type), dRNG payload (Payload), Salt declaration payload, generic data payload.', 'private tangle': 'A private tangle is comparable to a test network under complete control of the operator. This allows companies and developers to test their applications under self-defined environment variables without external influences and protected from prying eyes. There is no interoperability between a private Tangle and the IOTA or Shimmer Tangle. So, sending from one to the other does not work either. Each private Tangle is an independent network with its own nodes, tokens, and coordinator.', 'proof of work (pow)': @@ -195,8 +193,8 @@ module.exports = { 'Nodes have an upper limit on transactions per second (TPS) they can process. Through a type of database partitioning (breaking a very large database into smaller ones) into more manageable segments (shards), each shard would contain a unique set of account balances and nodes would then be assigned to individual shards to validate transactions. The goal is that by dividing into more manageable segments, it will increase transaction throughput and thus overcome scalability issues.', signatures: 'Signatures prove ownership of an address. Clients (Wallets) need this proof before nodes validate a transaction. To prove ownership, input transactions must be signed with the private key used to create the address.', - 'solidity (iota 2.0)': - 'A message is marked as solid if its entire past cone until the Genesis (or the latest snapshot) is known.', + solidity: + '(iota 2.0) A message is marked as solid if its entire past cone until the Genesis (or the latest snapshot) is known.', subtangle: 'A consistent section of the tangle (i.e., a subset of messages / value objects) such that each contained message / value object also contains its referenced messages / value objects.', streams: @@ -216,16 +214,16 @@ module.exports = { 'tip selection': 'The process of selecting previous transactions to be referenced by a new transaction. In these references, a transaction ties into the existing data structure. IOTA and Shimmer only enforces that a transaction approves up to eight other transactions, the tip selection strategy is left to the user (with a good default provided by Shimmer).', 'tip transaction': 'A solid end transaction that is not yet a parent.', - 'transaction (iota 2.0)': - 'A message that contains a Token transfer as a payload. The transferred tokens can be native IOTA Tokens or native IOTA Assets.', + transaction: + ' (iota 2.0) A message that contains a Token transfer as a payload. The transferred tokens can be native IOTA Tokens or native IOTA Assets.', 'utxo model': 'This is a so-called addressing model. UTXO stands for "unspent transaction output", which simply means that you not only keep track of the credits on the address, but also keep track of where the credits come from and where they are sent when they are spent. Each token on an address is thus uniquely identifiable and each issue names the exact token they want to move. This enables faster and more accurate conflict handling and improves the resilience and security of the protocol.', - 'value layer (iota 2.0)': - 'The Value layer builds on the Communication layer. It works exclusively with payloads of type Value object. This layer has several tasks: Forming the ledger state, processing, validation and output of transactions, conflict detection, conflict resolution via FPC, forming a DAG from value objects, tip selection (on value object tips).', + 'value layer': + '(iota 2.0) The Value layer builds on the Communication layer. It works exclusively with payloads of type Value object. This layer has several tasks: Forming the ledger state, processing, validation and output of transactions, conflict detection, conflict resolution via FPC, forming a DAG from value objects, tip selection (on value object tips).', 'value transactions': 'Value transactions either withdraw tokens from an address or deposit them to an address. Nodes must verify these transactions to ensure that the sender actually owns the Shimmer tokens and that additional tokens are never generated. To do this, the following checks are performed: All Shimmer tokens withdrawn from an address are also deposited into one or more other addresses; the value of each transaction does not exceed the total global supply; signatures are valid.', - 'version number (iota 2.0)': 'Indicates the correct format of each type.', - 'white-flag approach (iota 1.5)': - 'Used to calculate credits. A simpler, conflict-avoiding approach that improves the speed and efficiency of tip selection, eliminates certain attacks, and significantly reduces the need for reattachments.', + 'version number': '(iota 2.0) Indicates the correct format of each type.', + 'white-flag approach': + '(iota 1.5) Used to calculate credits. A simpler, conflict-avoiding approach that improves the speed and efficiency of tip selection, eliminates certain attacks, and significantly reduces the need for reattachments.', wasp: 'The Wasp node software is an implementation of Smart Contracts on the Tangle.', }; From e56ccb783f13471c1dff212a0746629a233ba924 Mon Sep 17 00:00:00 2001 From: Lucas Tortora Date: Fri, 4 Aug 2023 11:15:51 -0300 Subject: [PATCH 7/8] edit glossary --- common/jargon.js | 241 ++++++++++++++++++++++++----------------------- 1 file changed, 122 insertions(+), 119 deletions(-) diff --git a/common/jargon.js b/common/jargon.js index 401c10f3ddf..0f68b7f7011 100644 --- a/common/jargon.js +++ b/common/jargon.js @@ -1,229 +1,232 @@ module.exports = { 'address checksum': - 'Checksum validation is a way to determine if an address is valid and does not contain typos.', + 'Checksum validation is a method to ensure an address is valid and free of typographical errors.', 'dynamic pow': - '(In development for IOTA 1.5 and Shimmer): With this feature, the coordinator can issue a milestone and simultaneously set the future PoW score. This means that if the network is not fully utilized, the PoW will be reduced to the point where it can be executed by microdevices. Accordingly, the coordinator can also raise the PoW difficulty in case of high utilization and thus make an attack very expensive.', + '(In development for IOTA 1.5 and Shimmer): This feature enables the coordinator to issue a milestone while simultaneously setting the future PoW score. If the network is underutilized, the PoW will decrease to a level manageable by microdevices. Conversely, the coordinator can increase the PoW difficulty during high utilization, making attacks prohibitively expensive.', 'auto peering': - 'A mechanism that allows nodes to automatically select their neighbors without manual intervention by the node operator.', + "A mechanism enabling nodes to select their neighbors automatically, without the node operator's manual intervention.", 'API(application programming interfaces)': - 'The way for applications to interact with the Tangle.', + 'These interfaces facilitate interactions between applications and the Tangle.', 'atomic transactions': - 'Instead of the bundle construct, IOTA and Shimmer use simpler Atomic Transactions. An Atomic Transaction includes everything related to a transaction in a single message instead of splitting it up (Bundles). This reduces network overhead and signature verification load, improves spam protection and rate control, and shortens the length of Merkle proofs (for future sharding). It also reduces implementation overhead and increases maintainability of the core node software.', + 'Instead of the bundle construct, IOTA and Shimmer use simpler Atomic Transactions. These transactions encapsulate all related information within a single message, reducing network overhead, improving spam protection and rate control, and simplifying Merkle proofs. This simplification also lowers implementation overhead and enhances the maintainability of the core node software.', 'application layer': - '(iota 2.0) The top layer of the 3-layer communication protocol. The IOTA protocol allows a variety of external applications to run on the Message Tangle. Anyone can design an application and users can decide which applications to run on their nodes. These applications will all use the communication layer to transmit and store data.', + '(iota 2.0) The top layer of the 3-layer communication protocol. The IOTA protocol supports various external applications running on the Message Tangle. Applications can be designed by anyone, and users decide which applications to run on their nodes. All applications use the communication layer to transmit and store data.', 'approval switch': - '(iota 2.0) When a message is selected as a parent, we can choose from the strong or weak tip pool. This mechanism is called Approval Switch.', + '(iota 2.0) This mechanism allows for a selection between the strong or weak tip pool when a message is selected as a parent.', 'approval weight': - '(iota 2.0) A message gets Mana-weight by approving the message directly or indirectly. However, only strong parents can pass on the mana weight to the past, while weak parents receive the weight from their weak children but do not pass it on.', + '(iota 2.0) A message receives Mana-weight by direct or indirect approval. However, only strong parents can pass on the mana weight to the past, while weak parents receive the weight from their weak children but do not pass it on.', approvers: - '(iota 2.0)Parents are approved by their referencing messages called approvers. It is thus a reverse mapping of parents. As in the parents definition, an approver might be either strong or weak.', + "(iota 2.0) Parents are approved by their referencing messages, known as approvers. It's essentially a reverse mapping of parents. An approver might be either strong or weak, as in the parents' definition.", balance: - 'Funds on the addresses (account). These are always available and cannot be deleted or forgotten.', + 'The funds on the addresses (account). These are always available and cannot be deleted or forgotten.', 'blockchain bottleneck': - 'The more transactions are issued, the more the block rate and size become a bottleneck in the system. It is no longer possible to capture all incoming transactions in a prompt manner. Attempts to speed up block rates result in more orphaned blocks (blocks are left behind) and reduce the security of the blockchain.', + 'As more transactions are issued, the block rate and size become bottlenecks in the system. It becomes increasingly difficult to promptly process all incoming transactions. Attempts to speed up block rates result in more orphaned blocks (blocks left behind), reducing the security of the blockchain.', branch: - '(iota 2.0) A version of the ledger that temporarily coexists with other versions, each spawned by conflicting transactions.', - bee: '(Deprecated) Node software developed by the IOTA foundation using the Rust programming language.', + '(iota 2.0) This term refers to a version of the ledger that temporarily coexists with other versions, each spawned by conflicting transactions.', + bee: '(Deprecated) Node software developed by the IOTA foundation, written in the Rust programming language.', 'bootstrapping attack': - 'An attack in which a node downloads malicious snapshot files, including invalid transactions and balances.', - curl: 'This is one of the hash functions currently in use. It is based on the "sponge" construction of the Keccak inventors (SHA-3).', + 'An attack where a node downloads malicious snapshot files, including invalid transactions and balances.', + curl: "This is one of the currently used hash functions. It's based on the 'sponge' construction invented by the creators of Keccak (SHA-3).", confirmed: - 'Confirmed transactions. Messages in the Tangle are considered for confirmation only when they are directly or indirectly referenced by a milestone that the Coordinator node has validated. To allow the nodes to recognize the milestones, all nodes that participate in the same network are configured with the Merkle root address of a Coordinator that they trust to confirm messages. Using this address, nodes can validate the signatures in milestones to verify whether the trusted Coordinator signs them. To make sure that new messages always have a chance of being confirmed, the Coordinator sends indexed milestones at regular intervals. This way, nodes can compare the indexes of their milestones to check whether they are synchronized with the rest of the network.', + "Transactions are considered confirmed in the Tangle only when they are directly or indirectly referenced by a milestone validated by the Coordinator node. Nodes can recognize milestones because they're all configured with the Merkle root address of a Coordinator they trust to confirm messages. Using this address, nodes can validate the signatures in milestones to verify whether the trusted Coordinator signed them. To ensure that new messages always have a chance of being confirmed, the Coordinator regularly sends indexed milestones. This allows nodes to compare the indexes of their milestones and check whether they are synchronized with the rest of the network.", ctps: 'Confirmed transactions per second.', 'cumulative weight': - 'A system for valuing transactions. Each additional transaction that references a transaction increases its cumulative weight. When tips are selected, a path through transactions that has a higher cumulative weight is preferred.', + 'A system for valuing transactions. The cumulative weight of a transaction increases with each additional transaction that references it. A path through transactions with a higher cumulative weight is preferred when selecting tips.', chronicle: - "A permanode solution of the IOTA Foundation. It allows to store all transactions reaching a node in a distributed database that is secure and scales well. Chronicle is used to store the Tangle's unlimited data flow and make it queryable. In other words, permanence allows the entire history of the Tangle to be stored indefinitely and makes that data easily accessible.", + "A permanode solution from the IOTA Foundation. It enables storing all transactions reaching a node in a secure and scalable distributed database. Chronicle allows the Tangle's unlimited data flow to be stored indefinitely and makes it easily accessible.", consensus: - 'Agreement on a specific date or value in distributed multi-agent systems, in the presence of faulty processes.', - 'coordinator (only up to iota 2.0)': - 'A trusted entity, as protection against malicious transactions. The Tangle is not yet a final product, it is still in beta. The network currently relies on a kind of shield, the so-called coordinator. It is open-source and runs on a Hornet node. The COO acts as a centralized, voluntary, and temporary alternative consensus mechanism for the Tangle. To do this, the COO sends honest transactions to the full nodes at regular intervals. These packets contain a signed message with no value, called a milestone. The full nodes in the Tangle consider a transaction as confirmed only if it is approved by a milestone. Important: The coordinator can only confirm transactions, but he cannot bypass the consensus rules. To create, freeze or steal tokens is not possible for him. This fixed rule and the COO address is hardcoded on each full node, so the coordinator\u2019s influence on the tangle is very limited, since the tangle is also constantly monitored by all the other full nodes. > The Coo will be switched off with the IOTA 2.0 upgrade.', + 'Agreement on a specific date or value in distributed multi-agent systems, even in the presence of faulty processes.', + coordinator: + "(only up to iota 2.0) A trusted entity used as protection against malicious transactions. The Tangle is still in its beta phase and relies on the coordinator. This is open-source and runs on a Hornet node. The COO acts as a centralized, voluntary, and temporary alternative consensus mechanism for the Tangle by regularly sending honest transactions to the full nodes. These transactions contain a signed message with no value, called a milestone. Full nodes consider a transaction as confirmed only if it is approved by a milestone. The coordinator can confirm transactions but can't bypass consensus rules. Hence, creating, freezing, or stealing tokens is impossible for it. The coordinator's influence on the tangle is limited as the tangle is continuously monitored by all other full nodes. The COO will be switched off with the IOTA 2.0 upgrade.", 'communication layer': - '(iota 2.0) This layer stores and communicates information. This layer contains the distributed ledger or tangle. The rate control and timestamps are also located in this layer.', + '(iota 2.0) This layer stores and communicates information. It contains the distributed ledger or Tangle. The rate control and timestamps are also located in this layer.', 'core object type': - '(iota 2.0) An object type that must be parsed by all nodes. Parsers are computer programs responsible for decomposing and converting an input into a format more suitable for further processing.', + '(iota 2.0) This is an object type that all nodes must parse. Parsers are computer programs that decompose and convert input into a format more suitable for further processing.', 'core application': - '(iota 2.0) Core application that must be executed by all nodes, for example the value transfer application.', - child: '(iota 2.0) A transaction that gets referenced by Parents.', + '(iota 2.0) A core application is an application that all nodes must execute. For instance, the value transfer application.', + child: '(iota 2.0) A transaction that is referenced by Parents.', chrysalis: 'The name of the IOTA 1.5 network upgrade.', stardust: 'The name of the first Shimmer network upgrade.', - data: 'The tangle is a way of proving the integrity of data (verifiability of completeness and origin) in a trustworthy manner. At present, there are several cryptographic methods that make this possible, but security gaps are repeatedly discovered here, making data vulnerable to manipulation. This is a major problem, especially in cloud computing, where third-party audit tools are sometimes even used (for a fee) to ensure this data integrity. This is exactly where IOTA and Shimmer come in and offers a relatively easy way to escape this with its protocol and without fees.', + data: 'The Tangle proves the integrity of data (verifiability of completeness and origin) in a reliable manner. Current cryptographic methods for this have repeated security vulnerabilities, making data prone to manipulation. This is especially problematic in cloud computing where sometimes third-party audit tools are even used (for a fee) to ensure this data integrity. IOTA and Shimmer offer a relatively straightforward and fee-free solution to this with their protocol.', 'data transactions': 'These are confirmed directly and are notarized. With the help of "notarization", it can be proven that an electronic document existed in a certain form at a certain time and has not been changed since its creation. When a notarization is created, a unique hash (fingerprint) of a document is calculated and stored together with a timestamp in the ledger (Tangle) in an immutable manner.', 'data storage': - 'Just like the internet, the IOTA and Shimmer protocols do not store data or in other words, the Tangle is not a data storage. If someone wants to store the history of transactions in a decentralized way, they can build a second-layer solution for this themselves or pay third parties for this storage. For the basic layer, IOTA and Shimmer focus on performance, throughput, and security rather than building a global database.', + 'Contrary to the internet, neither the IOTA nor Shimmer protocols serve as data storage. The Tangle is not designed as a data repository. If one wishes to maintain a decentralized transaction history, they can either design a second-layer solution themselves or commission third parties for this task. At its core, IOTA and Shimmer prioritize performance, throughput, and security over acting as a global database.', 'distributed ledger technology (dlt)': - 'This is a database architecture that allows owners of digital assets to transfer and document them from peer to peer. Each transfer in a DLT is stored as a record in a distributed ledger (database). This database is stored in all nodes of a network.', + 'DLT is a database system that enables the peer-to-peer transfer and recording of digital assets. Each transaction within a DLT is recorded in a distributed ledger, which is maintained across all network nodes.', devnet: - 'The DevNet (developer network) is a pure test network to research and test a Tangle without Coordinator.', + 'DevNet, or developer network, is a dedicated test network to experiment with and test a Tangle that operates without a Coordinator.', decay: - 'Both Mana and pending Mana decay proportionally to its value, preventing Mana from growing indefinitely over time.', + 'Both Mana and pending Mana decay in proportion to their value, ensuring that Mana does not perpetually accumulate over time.', 'double-spending': - 'Double-spending is a threat to a digital money system, where the same single digital token can be spent more than once. Unlike physical money, a digital token consists of a digital file that can be duplicated or counterfeited.', + 'Double-spending represents a major threat to digital currency systems. It involves spending the same digital token more than once. Digital tokens, unlike physical currency, comprise digital files that can be easily duplicated or counterfeited.', 'drng (decentralized random number generator)': - 'This random number generator is required in Fast Probabilistic Consensus (FPC) to make the consensus model more resilient to attacks. In the case of conflicting transactions, the FPC votes on the transactions in question in several rounds. The threshold at which a node changes its mind in this vote is 50% +/- a small random deviation (using dRNG). In order to avoid stalemate or a specific outcome in the voting, this additional random component prevents potentially malicious nodes from influencing the voting process.', + 'dRNG is crucial for the Fast Probabilistic Consensus (FPC) as it fortifies the consensus model against attacks. For conflicting transactions, the FPC conducts several rounds of voting. The decision threshold for nodes is 50% plus or minus a slight random deviation generated by dRNG. This randomness prevents potential adversaries from manipulating the vote.', 'dust protection': - '(iota 1.5) Someone who wants to harm IOTA could automatically send 1i for years to repeatedly recreated addresses, driving up the ledger\u2019s memory requirements to the point where a full-node would eventually only run on large servers. In Chrysalis if you want to create a microtransaction (<1Mi) you need to activate dust on the receiving address. That will allow you to receive a certain amount of dust. Also, the addresses with Colored Coins have to be tokenized. After the Coordicide, there will be another solution for IOTA 2.0.', + '(iota 1.5) To prevent IOTA from being exploited, one might continually send 1i to newly generated addresses for years, causing the ledger’s memory requirements to surge until only large servers could operate a full node. With Chrysalis, microtransactions (<1Mi) require the recipient address to enable dust. This permits a limited amount of dust transactions. Additionally, addresses with Colored Coins must be tokenized. Post-Coordicide, IOTA 2.0 will introduce a different solution.', 'directed acyclic graph (dag)': - 'A directed acyclic graph is DLT structure that consists of edges and vertices that never form a closed loop. The Tangle is a form of directed acyclic graph.', + 'A directed acyclic graph (DAG) is a DLT structure made up of vertices and edges that never create a closed loop. The Tangle is a type of DAG.', 'eclipse attack': - 'A cyber-attack that aims to isolate a specific node rather than attack the entire network.', + 'An eclipse attack seeks to isolate a specific node rather than targeting the entire network.', 'eth virtual machine': - 'A VM is what executes the Smart Contract code so that it runs deterministically. The language in which you run the code provides hooks to access the sandbox on which the VM runs. In the case of Shimmer, this is the ISC sandbox, which only provides access to Shimmer tokens, thus consensus also runs on Shimmer tokens. It is only the VM that Shimmer works with, foreign tokens have nothing to do with a VM running the SC code, not the ETH VM, nor the Cartesi VM.', + "A virtual machine (VM) executes Smart Contract code to ensure deterministic outcomes. The programming language used to run the code provides hooks to the VM's sandbox. In Shimmer's context, this is the ISC sandbox, limited to Shimmer tokens, thereby ensuring consensus revolves around these tokens. The VM handles the execution of the smart contract code, unrelated to the token type, be it ETH VM or Cartesi VM.", epoch: - '(iota 2.0) A time interval used for a specific type of consensus mana. At the end of each epoch, a snapshot is taken of the state of mana distribution on the network. Since this tool uses the timestamp of messages, each node can eventually reach a consensus on the mana distribution of an epoch.', + "(iota 2.0) An epoch is a set time interval reserved for a specific consensus mana type. At every epoch's conclusion, the network captures a snapshot of the mana distribution. Given that this tool leverages timestamps of messages, each node can eventually agree on an epoch’s mana allocation.", faucet: - 'A pool of tokens (funds). Upon uncomplicated request, one gets a limited number of tokens for testing, especially for developers of own apps this is a great help.', + 'A faucet is a reservoir of tokens. Users can easily request a limited quantity of tokens for testing purposes, which proves particularly useful for app developers.', firefly: - 'Firefly is a wallet, intended to serve as a platform for the current and future IOTA and Shimmer ecosystem.', + 'Firefly is a wallet designed to cater to the present and future needs of the IOTA and Shimmer ecosystems.', finality: - 'The property that once a transaction has been completed, there is no way to reverse or change it. This is the moment when the parties involved in a transfer can consider the transaction completed. Finality can be deterministic or probabilistic.', - 'full nodes (hornet, bee)': - 'They form the core (infrastructure) of the network. In order to participate in the peer-to-peer network, the full node must always be online and connected to neighbors (other full nodes). In addition, the transaction database must be synchronized with all other full nodes in the network. The role of full nodes is to interact with clients (wallets, DApps, etc.) and attach their transactions to the ledger, make transactions known to all other full nodes in the network, validate transactions and store them in the ledger.', + "Finality indicates that once a transaction has been executed, it's irreversible and finalized. This is the juncture where the transaction parties recognize its completion. Finality can be deterministic or probabilistic.", + 'full nodes (hornet)': + "Full nodes constitute the network's backbone. For a full node to be part of the peer-to-peer network, it must always be online and connected to other full nodes. Moreover, it has to synchronize its transaction database with every other full node in the network. Full nodes process transactions from clients (like wallets and DApps), append them to the ledger, and share them with all other network nodes.", 'future cone': - 'All messages that directly or indirectly reference a message are called its future cone.', - fork: 'In IT, this is a new development branch after a project is split into a second follow-on project; the source code or parts of it are developed independently of the original parent project.', + 'The future cone refers to all messages that directly or indirectly reference a particular message.', + fork: 'In IT, a fork represents a new development direction taken after branching out from an original project. The source code, or portions of it, is then developed independently from the parent project.', 'fpc(fast probabilistic consensus)': - 'Consensus that uses a random number and node opinions to reach consensus. In On-Tangle Voting, it is only used in a specific edge case. Check out OTVFPCS.', + 'FPC is a consensus mechanism that employs a random number and node opinions to achieve consensus. In On-Tangle Voting, FPC is utilized only in specific edge cases. For more details, refer to OTVFPCS.', 'genesis transaction': - 'The Genesis transaction is the first transaction that created all IOTA and Shimmer tokens and distributed them to the addresses of the buyers.', + "The Genesis transaction is the inaugural transaction that spawned all IOTA and Shimmer tokens, distributing them to the purchasers' addresses.", 'goshimmer (no main net)': - 'Prototype of the coordinator less version of IOTA written in the Go programming language. GoShimmer implements the various modules of Coordicide, such as auto peering, node identities, Mana, etc. GoShimmer serves as a test environment for the first alpha version and the test network. Everything tested here will be gradually merged with Hornet and Bee.', + 'GoShimmer is a prototype of IOTA’s coordinator-less version written in the Go language. GoShimmer encapsulates various Coordicide modules, like auto peering, node identities, Mana, among others. It serves as a testing ground for the first alpha version and the testnet. Components tested in GoShimmer are systematically integrated with Hornet.', 'generic data object': - '(iota 2.0) The most basic object type. All unrecognized data objects are defined this way.', + '(iota 2.0) This is the most elementary object type. All unrecognized data objects are treated as generic data objects.', history: - 'The list of transactions that were directly or indirectly authorized by a particular transaction.', + 'History refers to the compilation of transactions that were directly or indirectly authorized by a specific transaction.', 'hash values': - 'Checksums that are applied to the encryption of messages of variable length. Hash values are like fingerprints of a very long data set. Each message is assigned a very specific hash value.', + 'Checksums generated from the encryption of variable-length messages. Hash values act like unique fingerprints for a long data set, with each message assigned a specific hash value.', hooks: - 'An interface that allows foreign program code to be integrated into an existing application to extend it, change its flow, or intercept certain events.', + 'Interfaces that allow external program code to be integrated into an existing application to extend its functionality, modify its flow, or intercept certain events.', 'hornet node': - 'Community-developed IOTA Node written in the Go programming language. In addition, the coordinator also runs as a plugin via Hornet.', + 'A community-developed IOTA Node written in the Go programming language. Additionally, the coordinator runs as a plugin via Hornet.', 'hornet node (shimmer)': - 'Shimmer Node written in the Go programming language. In addition, the coordinator also runs as a plugin via Hornet.', + 'A Shimmer Node, also written in the Go programming language. Similarly to the IOTA Node, the coordinator runs as a plugin via Hornet.', 'inclusion state': - 'Used to determine if a transaction has been accepted and confirmed by the network. Especially for a transaction and a list of tips: Inclusion state is true if the tip refers to this transaction.', + 'Determines whether a transaction has been accepted and confirmed by the network. For any given transaction and a list of tips, the inclusion state is true if the tip refers to that transaction.', 'local snapshots': - 'Local snapshots are used to limit the memory requirements of the nodes. For this purpose, on the individual nodes old, already confirmed, transactions are deleted from the database. What remains is only a small file (list) with the balances on the respective addresses. Nodes perform the snapshot independently and at their own discretion. This feature allows faster synchronization, lower system resource requirements and no more waiting for global snapshots to clean up the database.', + 'Local snapshots help limit the memory requirements of nodes by allowing them to independently delete old, confirmed transactions from their databases, leaving behind a small file with the balances of respective addresses. This feature facilitates faster synchronization, reduces system resource requirements, and eliminates the need to wait for global snapshots for database cleanup.', layer: - 'In DLT a 2nd-layer refers to a secondary framework or protocol built on top of an existing distributed ledger. On these second layers, other applications can be executed without putting too much strain on the base layer. For example, Smart Contracts.', + 'In DLT, a 2nd-layer refers to a secondary framework or protocol built on top of an existing distributed ledger. These secondary layers allow for additional applications to be executed without putting excessive strain on the base layer. Smart Contracts, for example, are executed on these second layers.', 'local modifiers': - 'User-defined conditions that can be considered by nodes during tip selection. In IOTA and Shimmer, nodes do not necessarily have the same view of the tangle. Different types of information that are only available to them locally can be used to strengthen security.', + 'User-defined conditions that nodes can consider during tip selection. In IOTA and Shimmer, nodes may not necessarily have the same view of the tangle. They can use various types of locally available information to enhance security.', 'merkle tree': - 'A Merkle tree is a data structure used in computer science applications. In cryptocurrencies, Merkle trees are used to encode more efficiently and securely.', + 'A Merkle tree is a data structure employed in computer science. In cryptocurrencies, Merkle trees are utilized for efficient and secure data encoding.', mainnet: - 'The public usable IOTA network, in which the IOTA tokens are used that are traded on cryptocurrency exchanges.', + 'The publicly accessible IOTA network where tradable IOTA tokens on cryptocurrency exchanges are used.', milestone: - '(iota 1.5) Milestones are messages that are signed and issued by the coordinator. Their main goal is to help the Tangle grow healthily and guarantee finality. When milestones directly or indirectly approve a transaction in the Tangle, nodes mark the status of that transaction and its entire history as confirmed.', + '(IOTA 1.5) Milestones are messages signed and issued by the coordinator. They are instrumental in ensuring healthy growth of the Tangle and guaranteeing finality. When milestones directly or indirectly approve a transaction in the Tangle, nodes mark the status of that transaction and its entire history as confirmed.', message: - 'A message is a core data type that reflects a vertex in the communication layer DAG. It contains the following properties: References to other messages, the sender\u2019s public key, the issuing time of the message, the message sequence number from the node that issued the message, the payload that can be interpreted by higher layers, the nonce that the message uses to satisfy the PoW requirement, a signature that signs all of the above fields. A message is not forwarded until it becomes "solid", i.e., its history is known to the node. Messages must meet a PoW requirement, which currently is to find a nonce so that the hash of the message\u2019s fields (minus the signature) has a certain number of leading zeros.', + "A message is a core data type that represents a vertex in the communication layer's DAG. It contains properties like references to other messages, the sender's public key, the issuing time of the message, the payload (interpretable by higher layers), the nonce for PoW requirement, and a signature. A message is not forwarded until it becomes \"solid,\" i.e., its history is known to the node. Messages must meet a PoW requirement, which currently involves finding a nonce so that the hash of the message's fields (excluding the signature) has a certain number of leading zeros.", 'message overhead': - 'The additional information (metadata) that must be sent along with the actual information (data). This can include signatures, polls and anything that is transmitted over the network but is not the transaction itself.', - mana: ' (iota 2.0) When a value transaction is processed, a quantity called Mana will be "pledged" to a specified node ID. This quantity is related to the amount of IOTA moved into the transaction. The only way to gain Mana is to convince some token holder to pledge it to you. In this sense, Mana is Delegated Proof of Token Ownership. Mana, therefore, provides adequate Sybil protection because it is difficult to acquire it in arbitrary amounts.', + 'The extra information (metadata) that must be sent along with the actual data. This may include signatures, polls, and any other data transmitted over the network that is not the transaction itself.', + mana: '(iota 2.0) When a value transaction is processed, a quantity named Mana is "pledged" to a specified node ID. This quantity correlates with the amount of IOTA involved in the transaction. The only way to acquire Mana is by persuading a token holder to pledge it to you. As such, Mana serves as a Delegated Proof of Token Ownership and offers robust Sybil protection due to its challenging acquisition process.', markers: - '(iota 2.0) A tool that exists only locally and allows certain calculations to be performed more efficiently, such as the calculation of the approval weight or the presence of certain messages in the past or future cone of another message.', + '(iota 2.0) A local tool that enhances efficiency in certain calculations, such as the computation of approval weight or determining the presence of specific messages in the past or future cone of another message.', 'messages per second (mps)': - 'The amount of messages issued to the network every second.', + 'Represents the number of messages dispatched to the network every second.', 'nakamoto consensus': - 'Named after the creator of Bitcoin, Satoshi Nakamoto, the Nakamoto Consensus describes the replacement of coordination / communication between known agents with a cryptographic puzzle (Proof-of-Work). Completion of the puzzle determines which agent acts next.', + "Named after Bitcoin's creator, Satoshi Nakamoto, this consensus describes the use of a cryptographic puzzle (Proof-of-Work) to replace coordination/communication between known agents. Solving the puzzle determines the subsequent agent's action.", neighbors: - 'Network nodes that are directly connected and can exchange messages without intermediate nodes.', + 'Directly connected network nodes that can exchange messages without intermediary nodes.', nodes: - 'A node is any computer that connects to other nodes in the network via software. In principle, they serve as a connection point for data transfers. The Tangle works with different types of nodes, such as full nodes (Hornet, Bee), permanodes (Chronicle) or smart contract nodes (Wasp).', + 'A node is any computer that communicates with other nodes in the network using specific software. Essentially, nodes act as connection points for data transfers. The Tangle employs various node types, including full nodes (Hornet, Bee), permanodes (Chronicle), and smart contract nodes (Wasp).', 'network layer': - '(iota 2.0) This layer manages the lower layers of Internet communication such as TCP. In this layer, the connections between the nodes are managed by the Auto peering and Peer Discovery modules and the Gossip protocol.', + '(iota 2.0) This layer oversees the lower levels of Internet communication, such as TCP. It manages node connections through the Auto-peering, Peer Discovery modules, and the Gossip protocol.', 'network id': - 'The network ID enables user-specific subtangles in which nodes can only recognize messages from the network ID listed in their configuration file.', + 'An identifier enabling user-specific subtangles. Nodes can only recognize messages from the network ID stipulated in their configuration file.', orphan: - 'A transaction (or block) that is not referenced by any subsequent transaction (or block). An orphan is not considered confirmed and will not be part of the consensus.', + 'A transaction (or block) lacking references from any subsequent transaction (or block). Orphans are unconfirmed and remain excluded from consensus.', object: - ' (iota 2.0) The most basic unit of information in the IOTA protocol. Each object has a type and size and contains data.', + '(iota 2.0) The fundamental unit of information in the IOTA protocol. Each object possesses a type, size, and data.', oracles: - 'Oracles are designed to build a secure bridge between the digital and physical worlds in a decentralized, permissionless way. They bring off-chain data to decentralized applications and smart contracts on the network.', - otv: '(iota 2.0) On Tangle Voting is the official name for the multiverse consensus described by Hans Moog. It is a new consensus mechanism that allows nodes to vote on conflicts directly by publishing a message to the tangle.', + 'Oracles establish a secure, decentralized bridge between digital and physical realms. They introduce off-chain data to decentralized applications and smart contracts within the network.', + otv: "(iota 2.0) On Tangle Voting, known as the multiverse consensus articulated by Hans Moog. It's a novel consensus mechanism allowing nodes to vote on conflicts by publishing a message to the tangle.", otvfpcs: - '(iota 2.0) On Tangle Voting with FPCS (Fast Probabilistic Consensus on a Set) is a mechanism for breaking metastability, which can be used in addition to OTV (On Tangle Voting). Generally, in IOTA2.0, reaching a high approval weight is the finality criteria. If the approval weight is high enough, the message / transaction is finalized. With OTVFPC the initial opinion is created with OTV, if after some time the opinions of the nodes are still split, for whatever reason, FPC is activated to break this metastable state. The finality of value transactions should be reached faster this way.', + '(iota 2.0) On Tangle Voting with FPCS (Fast Probabilistic Consensus on a Set) is a method designed to resolve metastability. In IOTA 2.0, achieving high approval weight signals finality. If this weight is sufficiently high, the message/transaction is confirmed. With OTVFPC, OTV forms the initial opinion. If node opinions remain divided over time, FPC initiates to resolve this metastable state, expediting transaction finality.', parents: - 'A message directly references up to 8 previous messages that we call its parents. In IOTA 2.0 a parent can be either strong or weak (see approval switch).', + 'A message can directly reference up to 8 preceding messages, known as its parents. In IOTA 2.0, a parent might be either strong or weak (see approval switch).', 'parallel reality ledger state': - '(iota 2.0) This state is used to track conflicts in the tangle. Two new ledger entries that are causally valid but in conflict with each other (ex. Double Spend) are posted into two separate "realities" for this purpose, representing possible but mutually exclusive future ledger states. The consensus mechanism (with FPC, etc.) will now operate until the perception of most nodes tilts in one direction and one of the two possible ledger states is accepted as true.', + '(iota 2.0) A state to monitor tangle conflicts. Two conflicting but causally valid ledger entries (e.g., Double Spend) are placed into separate "realities." These represent potential but exclusive future ledger states. The consensus mechanism, aided by FPC, operates until most nodes\' perceptions align, leading to the acceptance of one true ledger state.', 'partition tolerant': - 'This means that a part of the Tangle can be disconnected from the main tangle for a certain time and continue to run without an Internet connection. These parts can be reconnected to the main Tangle when the Internet connection is restored.', + 'A segment of the Tangle can operate offline, disconnected from the main tangle for a duration, and later reconnect once an Internet connection resumes.', 'past cone': - 'All messages that are directly or indirectly referenced by a message are called its past cone.', + 'The set of messages that are directly or indirectly referenced by a given message is termed its past cone.', 'parasite chain attacks': - 'A double spending attack on the Tangle. Here, an attacker attempts to reverse a transaction by setting up an alternate Tangle in which the funds were not spent. He then tries to get the majority of the network to accept the alternative Tangle as the legitimate one.', + 'A double-spending attack targeting the Tangle. Attackers attempt to reverse a transaction by creating an alternate Tangle where the funds remain unspent, seeking to convince the network majority to accept this version as legitimate.', permanode: - 'This type of node permanently stores the entire transaction history, possibly with the help of external storage solutions, and possibly only specific transactions (selective permanode).', - pending: 'A transaction has been seen by the network but not yet confirmed.', + 'This node type permanently retains the entire transaction history, potentially with external storage aids, or selectively stores specific transactions (selective permanode).', + pending: + 'A transaction that has been propagated through the network but not yet confirmed.', 'peer to peer network': - 'A decentralized network of different network nodes that are connected to each other and exchange data.', - peering: 'The process of discovering and connecting to other network nodes.', + 'A decentralized network comprising distinct nodes interconnected and engaged in data exchange.', + peering: + 'The procedure of detecting and establishing connections with other network nodes.', payload: - '(iota 2.0)A field in a message that determines the type. Examples are value payload (TransactionType type), FPC opinion payload (StatementType type), dRNG payload (Payload), Salt declaration payload, generic data payload.', + '(iota 2.0) A message field specifying the type. Examples include value payload (TransactionType type), FPC opinion payload (StatementType type), dRNG payload (Payload), Salt declaration payload, generic data payload.', 'private tangle': - 'A private tangle is comparable to a test network under complete control of the operator. This allows companies and developers to test their applications under self-defined environment variables without external influences and protected from prying eyes. There is no interoperability between a private Tangle and the IOTA or Shimmer Tangle. So, sending from one to the other does not work either. Each private Tangle is an independent network with its own nodes, tokens, and coordinator.', + "A private tangle functions akin to a test network entirely under the operator's control. It allows companies and developers to test their applications in a controlled environment, free from external influences and away from prying eyes. There is no interoperability between a private Tangle and the IOTA or Shimmer Tangle, prohibiting any transmission between them. Each private Tangle operates as an independent network with its own nodes, tokens, and coordinator.", 'proof of work (pow)': - 'A time-consuming (expensive) mathematical calculation that uses computational power to prevent spam attacks. It consists of a difficult cryptographic puzzle that is easy to verify.', + 'A computationally intensive mathematical operation that prevents spam attacks by requiring a costly cryptographic puzzle solution that is, nonetheless, easy to validate.', 'proof of inclusion (poi)': - 'With PoI, one is able to provide evidence that a transaction was indirectly referenced by another transaction without having to present the full chain of actual transactions between the two transactions. This is done by using a sequence of hashes instead of the actual transaction data to prove the inclusion of a transaction (inclusion) in the referenced subtangle.', + 'PoI enables proving that a transaction was indirectly referenced by another without needing to present the entire chain of transactions linking them. Instead, a sequence of hashes replaces actual transaction data to validate the inclusion of a transaction in the referenced subtangle.', pruning: - 'In computer science, this is a term for simplifying, shortening, and optimizing decision trees. In Shimmer, this is done by local snapshots on each full node. Old transactions that have already been confirmed are deleted from the database, leaving only a file (list) of credits on each address.', + 'In computer science, pruning refers to the simplification, truncation, and optimization of decision trees. In Shimmer, this is achieved by local snapshots on each full node. Confirmed transactions are removed from the database, leaving only a list of balances for each address.', 'public and private keys': - 'These are used in cryptographic systems which use key pairs. There are public keys which can be shared and private keys which are known only to the owner. The generation of such keys depends on cryptographic algorithms based on mathematical problems to generate one-way functions. Effective security requires keeping the private key to remain only known to the owner. Public keys derived from this private key can be shared and used by others to verify ownership of the private key, without exposing the private key. Public keys function as addresses in IOTA and Shimmer.', + 'These are essential components of cryptographic systems utilizing key pairs, consisting of public keys, which can be shared, and private keys known only to the owner. The generation of these keys depends on cryptographic algorithms based on mathematical problems yielding one-way functions. Security depends on the private key remaining private. Public keys derived from the private key can be shared and used to verify ownership of the private key without revealing it. In IOTA and Shimmer, public keys function as addresses.', rebroadcast: - 'Repeats the sending of a transaction. While a transaction is being sent to a node, it may go offline. In this case, the node may not forward the transactions to its neighbors, and the rest of the network will never see these transactions. As a result, that transaction will never be referenced by the coordinator and thus never confirmed. Resending a bundle means resending the same bundle to a node. This way you give your transactions another chance to be forwarded to the rest of the network.', + 'Rebroadcasting involves retransmitting a transaction. If a node goes offline while a transaction is being sent, it may not relay the transactions to its neighbors, making these transactions invisible to the network. Consequently, these transactions will never be referenced by the coordinator and hence never confirmed. Resending a bundle refers to transmitting the same bundle to a node, providing another opportunity for your transactions to be relayed to the network.', 'reusable addresses': - 'With the introduction of the Ed25519 signature scheme, through the IOTA 1.5 Chrysalis upgrade, reusable addresses are now supported.', + 'Following the IOTA 1.5 Chrysalis upgrade and the introduction of the Ed25519 signature scheme, reusable addresses are now possible.', reattachment: - 'Resending a transaction by re-selecting a tip and referencing newer tips by repeating PoW.', - salt: 'In cryptography, salt is a randomly chosen string of characters that is appended to a given plaintext before it is further processed to increase the entropy (disorder) of the input. It is often used for storing and transmitting passwords to increase information security.', - sandbox: 'An isolated area where programs can be tested.', + 'The process of resending a transaction through the reselection of a tip, referencing newer tips, and performing PoW again.', + salt: "In cryptography, a salt is a random string appended to plaintext before further processing, thereby enhancing input entropy (disorder). It's commonly used in password storage and transmission to bolster information security.", + sandbox: 'A controlled environment where programs can be tested safely.', 'software as a service (saas)': - 'The SaaS model is a subset of cloud computing. It is based on the principle that the software and IT infrastructure can be operated by an external service provider and rented by the customer as a service.', + 'SaaS is a subset of cloud computing, based on the principle that the software and IT infrastructure are managed by an external service provider and leased to the customer as a service.', 'smart contract': - 'Smart contracts are contracts or programs that are automatically executed.', + 'Smart contracts are programs that execute contracts automatically.', 'smart contract chain': - 'Smart contracts are processed via a so-called contract chain, the representation of the contract state. A smart contract writes its state every time it is requested, and a new block is added for each of these state updates. All these updates are collected and confirmed in one block. So, the chain also contains all the past states. The chain can contain many Smart Contracts, all working on the same global state of the chain. From this perspective, the Contract chain is essentially a blockchain anchored on the Tangle. IOTA Smart Contracts can be considered "classic" Smart Contracts, but with the added feature that you can have multiple such parallel chains all using the same native IOTA and Shimmer tokens, and trading between them in a trusted manner on the Tangle. This enables trusted interoperability between different applications.', + 'Smart contracts operate through a contract chain, which represents the contract state. Every request to a smart contract adds a new block to this chain. These updates are confirmed in one block, also containing all past states. The chain can contain multiple Smart Contracts all working on the same global state. Essentially, the Contract chain is a blockchain anchored on the Tangle. IOTA Smart Contracts are similar to "classic" Smart Contracts but feature multiple parallel chains that use the same native IOTA and Shimmer tokens, enabling trusted interoperability between different applications.', 'solidification time': - 'The time of solidification when the entire history of a transaction has been received by a node.', + 'Solidification time is when a node has received the entire history of a transaction.', 'splitting attacks': - 'An attack in which a malicious node attempts to split the tangle into two branches. As one of the branches grows, the attacker publishes transactions on the other branch to keep both alive. Splitting attacks attempt to slow down the consensus process or perform double spending.', + 'An attack in which a malicious node tries to split the Tangle into two branches. Splitting attacks aim to slow down the consensus process or enable double spending.', sharding: - 'Nodes have an upper limit on transactions per second (TPS) they can process. Through a type of database partitioning (breaking a very large database into smaller ones) into more manageable segments (shards), each shard would contain a unique set of account balances and nodes would then be assigned to individual shards to validate transactions. The goal is that by dividing into more manageable segments, it will increase transaction throughput and thus overcome scalability issues.', + 'Sharding is a type of database partitioning that divides a large database into smaller, more manageable segments, or shards. Each shard contains a unique set of account balances, and nodes are assigned to individual shards to validate transactions. The goal is to increase transaction throughput and thus address scalability issues.', signatures: - 'Signatures prove ownership of an address. Clients (Wallets) need this proof before nodes validate a transaction. To prove ownership, input transactions must be signed with the private key used to create the address.', + 'Signatures prove ownership of an address. Nodes require this proof to validate a transaction. To prove ownership, input transactions must be signed with the private key used to create the address.', solidity: - '(iota 2.0) A message is marked as solid if its entire past cone until the Genesis (or the latest snapshot) is known.', + '(iota 2.0) A message is marked as solid if its entire past cone up to the Genesis (or the latest snapshot) is known.', subtangle: - 'A consistent section of the tangle (i.e., a subset of messages / value objects) such that each contained message / value object also contains its referenced messages / value objects.', + 'A consistent section of the Tangle (i.e., a subset of messages / value objects) such that each contained message/value object also contains its referenced messages/value objects.', streams: - 'IOTA Streams is a multifunctional second layer data transfer protocol that can be used for various types of data transfer (e.g., streaming data). For example, it allows sensors and other devices to encrypt entire data streams and anchor them in the IOTA Tangle. IOTA\u2019s consensus protocol adds integrity and authenticity to these message streams. Given these characteristics, IOTA Streams fills an important need in industries where integrity, privacy, and immutability collide.', + "IOTA Streams is a second layer data transfer protocol used for various types of data transfer, including streaming data. It allows devices to encrypt entire data streams and anchor them in the IOTA Tangle. IOTA's consensus protocol ensures the integrity and authenticity of these message streams. This makes IOTA Streams particularly useful in industries where integrity, privacy, and immutability are crucial.", 'sybil attack': - 'An attempt to gain control of a peer-to-peer network by forging multiple false identities.', + 'An attempt to take control of a peer-to-peer network by creating multiple false identities.', snapshot: - 'A special feature of the Tangle. A snapshot deletes all transactions. Only transactions with a balance > 0 are kept. The metadata such as tags and messages are also deleted. What is left behind is just a list of addresses and balances. After a snapshot, the nodes use this list as "genesis", a new starting point for the tangle. This reduces the size of the tangle network, allowing nodes to use less memory. Full nodes perform what are called "Local Snapshots" independently and at their own discretion.', + 'A snapshot is a special feature of the Tangle that removes all transactions, keeping only those with a balance > 0. Metadata like tags and messages are also deleted, leaving a list of addresses and balances. After a snapshot, nodes use this list as the new "genesis" or starting point for the Tangle. This reduces the size of the Tangle, allowing nodes to use less memory. Full nodes can perform "Local Snapshots" independently and at their own discretion.', tangle: - 'The Tangle is the underlying core data structure. In mathematical terms it is a directed acyclic graph (DAG). The Tangle is the distributed ledger that stores all transactions.', + 'The Tangle is the core underlying data structure of IOTA. In mathematical terms, it is a directed acyclic graph (DAG). The Tangle is the distributed ledger storing all transactions.', 'ternary system': - 'A trit (trinary digit) can have exactly three states (3 x 1 = 3): -1, 0 and 1. Three trits result in one tryte (33 = 27) and can thus represent 27 combinations. In IOTA, the letters A-Z (26 pieces) and the number 9 are used for this purpose.', + 'A trit (trinary digit) can have three states: -1, 0 and 1. Three trits result in one tryte, which can thus represent 27 combinations. In IOTA, the letters A-Z (26 in total) and the number 9 are used for this purpose.', token: - 'The digital currency form (cryptocurrency). It is a powerful tool for value transfer between people and machines. Total number: 2,779,530,283,277,761 IOTA. The base units are Pi, Ti, Gi, Mi, ki, i', - 'trinity (iota 1.0)': 'Depreciated IOTA Wallet', + 'The digital currency form (cryptocurrency) of IOTA. It is a powerful tool for transferring value between people and machines. The total number of IOTA tokens is 2,779,530,283,277,761. The base units are Pi, Ti, Gi, Mi, ki, i', + 'trinity (iota 1.0)': 'The deprecated IOTA Wallet', tip: 'A transaction that has not yet been approved.', 'tip selection': - 'The process of selecting previous transactions to be referenced by a new transaction. In these references, a transaction ties into the existing data structure. IOTA and Shimmer only enforces that a transaction approves up to eight other transactions, the tip selection strategy is left to the user (with a good default provided by Shimmer).', - 'tip transaction': 'A solid end transaction that is not yet a parent.', + 'The process of selecting previous transactions to reference in a new transaction. These references allow a transaction to tie into the existing data structure. IOTA and Shimmer only enforce that a transaction approves up to eight other transactions, the tip selection strategy is left to the user (with a suitable default provided by Shimmer).', + 'tip transaction': + 'A solid end transaction that has not yet become a parent.', transaction: - ' (iota 2.0) A message that contains a Token transfer as a payload. The transferred tokens can be native IOTA Tokens or native IOTA Assets.', + '(iota 2.0) A message that contains a Token transfer as a payload. The transferred tokens can be native IOTA Tokens or native IOTA Assets.', 'utxo model': - 'This is a so-called addressing model. UTXO stands for "unspent transaction output", which simply means that you not only keep track of the credits on the address, but also keep track of where the credits come from and where they are sent when they are spent. Each token on an address is thus uniquely identifiable and each issue names the exact token they want to move. This enables faster and more accurate conflict handling and improves the resilience and security of the protocol.', + 'UTXO stands for "unspent transaction output". It is a type of addressing model that tracks not only the credits on an address but also their origins and destinations when spent. Each token on an address is uniquely identifiable, and each output names the exact token it wants to move. This model enables faster and more accurate conflict resolution, enhancing the protocol\'s resilience and security.', 'value layer': - '(iota 2.0) The Value layer builds on the Communication layer. It works exclusively with payloads of type Value object. This layer has several tasks: Forming the ledger state, processing, validation and output of transactions, conflict detection, conflict resolution via FPC, forming a DAG from value objects, tip selection (on value object tips).', + '(iota 2.0) The Value layer builds on the Communication layer. It works exclusively with payloads of type Value object. This layer has several responsibilities: forming the ledger state, processing, validating and outputting transactions, conflict detection, conflict resolution via FPC, forming a DAG from value objects, tip selection (on value object tips).', 'value transactions': - 'Value transactions either withdraw tokens from an address or deposit them to an address. Nodes must verify these transactions to ensure that the sender actually owns the Shimmer tokens and that additional tokens are never generated. To do this, the following checks are performed: All Shimmer tokens withdrawn from an address are also deposited into one or more other addresses; the value of each transaction does not exceed the total global supply; signatures are valid.', + 'Value transactions either withdraw tokens from an address or deposit them to an address. Nodes verify these transactions to ensure that the sender owns the Shimmer tokens and that additional tokens are not generated. To do this, the following checks are performed: All Shimmer tokens withdrawn from an address are also deposited into one or more other addresses; the value of each transaction does not exceed the total global supply; signatures are valid.', 'version number': '(iota 2.0) Indicates the correct format of each type.', 'white-flag approach': - '(iota 1.5) Used to calculate credits. A simpler, conflict-avoiding approach that improves the speed and efficiency of tip selection, eliminates certain attacks, and significantly reduces the need for reattachments.', - wasp: 'The Wasp node software is an implementation of Smart Contracts on the Tangle.', + '(iota 1.5) A simplified, conflict-avoiding approach that improves the speed and efficiency of tip selection, eliminates certain attacks, and significantly reduces the need for reattachments.', + wasp: 'Wasp is the node software that implements Smart Contracts on the Tangle.', }; From 9147175c5f496bc2c0450cc6c0345060897a4332 Mon Sep 17 00:00:00 2001 From: Lucas Tortora Date: Fri, 4 Aug 2023 11:25:25 -0300 Subject: [PATCH 8/8] fix linting errors in action --- theme/src/theme/Glossary/index.tsx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/theme/src/theme/Glossary/index.tsx b/theme/src/theme/Glossary/index.tsx index c13206e827f..57f263e0742 100644 --- a/theme/src/theme/Glossary/index.tsx +++ b/theme/src/theme/Glossary/index.tsx @@ -14,11 +14,11 @@ export default function Glossary() { return acc; }, {}); - var char = ''; + let char = ''; return ( <> {Object.entries(sortedGlossary).map(([key, value]) => { - var heading = null; + let heading = null; if (key.charAt(0) !== char) { char = key.charAt(0); heading = char;