diff --git a/.github/workflows/code-quality.yml b/.github/workflows/code-quality.yml index c0677ad..bb53efc 100644 --- a/.github/workflows/code-quality.yml +++ b/.github/workflows/code-quality.yml @@ -11,6 +11,10 @@ jobs: steps: - uses: actions/checkout@v4 + - uses: actions/setup-node@v4 + with: + node-version: 24.x + - uses: oven-sh/setup-bun@v2 with: bun-version: latest @@ -46,6 +50,10 @@ jobs: steps: - uses: actions/checkout@v4 + - uses: actions/setup-node@v4 + with: + node-version: 24.x + - uses: oven-sh/setup-bun@v2 with: bun-version: latest diff --git a/website/bun.lock b/website/bun.lock index 262a244..42b949f 100644 --- a/website/bun.lock +++ b/website/bun.lock @@ -5,9 +5,11 @@ "": { "name": "quantus-website", "dependencies": { - "@astrojs/mdx": "^4.3.13", - "@astrojs/react": "^4.4.0", - "@astrojs/sitemap": "^3.5.1", + "@astrojs/mdx": "5.0.2", + "@astrojs/react": "5.0.1", + "@astrojs/sitemap": "3.7.1", + "@fontsource/ibm-plex-mono": "^5.2.7", + "@fontsource/ibm-plex-sans": "^5.2.8", "@fontsource/inter": "^5.2.6", "@fontsource/prompt": "^5.2.6", "@lucide/astro": "^0.541.0", @@ -17,7 +19,7 @@ "@tailwindcss/typography": "^0.5.19", "@tailwindcss/vite": "^4.1.12", "@tanstack/react-table": "^8.21.3", - "astro": "^5.13.2", + "astro": "6.0.7", "astro-seo": "^0.8.4", "chart.js": "^4.5.1", "chartjs-plugin-datalabels": "^2.2.0", @@ -52,19 +54,19 @@ "@astrojs/compiler": ["@astrojs/compiler@2.13.1", "", {}, "sha512-f3FN83d2G/v32ipNClRKgYv30onQlMZX1vCeZMjPsMMPl1mDpmbl0+N5BYo4S/ofzqJyS5hvwacEo0CCVDn/Qg=="], - "@astrojs/internal-helpers": ["@astrojs/internal-helpers@0.7.5", "", {}, "sha512-vreGnYSSKhAjFJCWAwe/CNhONvoc5lokxtRoZims+0wa3KbHBdPHSSthJsKxPd8d/aic6lWKpRTYGY/hsgK6EA=="], + "@astrojs/internal-helpers": ["@astrojs/internal-helpers@0.8.0", "", { "dependencies": { "picomatch": "^4.0.3" } }, "sha512-J56GrhEiV+4dmrGLPNOl2pZjpHXAndWVyiVDYGDuw6MWKpBSEMLdFxHzeM/6sqaknw9M+HFfHZAcvi3OfT3D/w=="], "@astrojs/language-server": ["@astrojs/language-server@2.16.3", "", { "dependencies": { "@astrojs/compiler": "^2.13.0", "@astrojs/yaml2ts": "^0.2.2", "@jridgewell/sourcemap-codec": "^1.5.5", "@volar/kit": "~2.4.27", "@volar/language-core": "~2.4.27", "@volar/language-server": "~2.4.27", "@volar/language-service": "~2.4.27", "muggle-string": "^0.4.1", "tinyglobby": "^0.2.15", "volar-service-css": "0.0.68", "volar-service-emmet": "0.0.68", "volar-service-html": "0.0.68", "volar-service-prettier": "0.0.68", "volar-service-typescript": "0.0.68", "volar-service-typescript-twoslash-queries": "0.0.68", "volar-service-yaml": "0.0.68", "vscode-html-languageservice": "^5.6.1", "vscode-uri": "^3.1.0" }, "peerDependencies": { "prettier": "^3.0.0", "prettier-plugin-astro": ">=0.11.0" }, "optionalPeers": ["prettier", "prettier-plugin-astro"], "bin": { "astro-ls": "bin/nodeServer.js" } }, "sha512-yO5K7RYCMXUfeDlnU6UnmtnoXzpuQc0yhlaCNZ67k1C/MiwwwvMZz+LGa+H35c49w5QBfvtr4w4Zcf5PcH8uYA=="], - "@astrojs/markdown-remark": ["@astrojs/markdown-remark@6.3.10", "", { "dependencies": { "@astrojs/internal-helpers": "0.7.5", "@astrojs/prism": "3.3.0", "github-slugger": "^2.0.0", "hast-util-from-html": "^2.0.3", "hast-util-to-text": "^4.0.2", "import-meta-resolve": "^4.2.0", "js-yaml": "^4.1.1", "mdast-util-definitions": "^6.0.0", "rehype-raw": "^7.0.0", "rehype-stringify": "^10.0.1", "remark-gfm": "^4.0.1", "remark-parse": "^11.0.0", "remark-rehype": "^11.1.2", "remark-smartypants": "^3.0.2", "shiki": "^3.19.0", "smol-toml": "^1.5.2", "unified": "^11.0.5", "unist-util-remove-position": "^5.0.0", "unist-util-visit": "^5.0.0", "unist-util-visit-parents": "^6.0.2", "vfile": "^6.0.3" } }, "sha512-kk4HeYR6AcnzC4QV8iSlOfh+N8TZ3MEStxPyenyCtemqn8IpEATBFMTJcfrNW32dgpt6MY3oCkMM/Tv3/I4G3A=="], + "@astrojs/markdown-remark": ["@astrojs/markdown-remark@7.0.1", "", { "dependencies": { "@astrojs/internal-helpers": "0.8.0", "@astrojs/prism": "4.0.1", "github-slugger": "^2.0.0", "hast-util-from-html": "^2.0.3", "hast-util-to-text": "^4.0.2", "js-yaml": "^4.1.1", "mdast-util-definitions": "^6.0.0", "rehype-raw": "^7.0.0", "rehype-stringify": "^10.0.1", "remark-gfm": "^4.0.1", "remark-parse": "^11.0.0", "remark-rehype": "^11.1.2", "remark-smartypants": "^3.0.2", "shiki": "^4.0.0", "smol-toml": "^1.6.0", "unified": "^11.0.5", "unist-util-remove-position": "^5.0.0", "unist-util-visit": "^5.1.0", "unist-util-visit-parents": "^6.0.2", "vfile": "^6.0.3" } }, "sha512-zAfLJmn07u9SlDNNHTpjv0RT4F8D4k54NR7ReRas8CO4OeGoqSvOuKwqCFg2/cqN3wHwdWlK/7Yv/lMXlhVIaw=="], - "@astrojs/mdx": ["@astrojs/mdx@4.3.13", "", { "dependencies": { "@astrojs/markdown-remark": "6.3.10", "@mdx-js/mdx": "^3.1.1", "acorn": "^8.15.0", "es-module-lexer": "^1.7.0", "estree-util-visit": "^2.0.0", "hast-util-to-html": "^9.0.5", "piccolore": "^0.1.3", "rehype-raw": "^7.0.0", "remark-gfm": "^4.0.1", "remark-smartypants": "^3.0.2", "source-map": "^0.7.6", "unist-util-visit": "^5.0.0", "vfile": "^6.0.3" }, "peerDependencies": { "astro": "^5.0.0" } }, "sha512-IHDHVKz0JfKBy3//52JSiyWv089b7GVSChIXLrlUOoTLWowG3wr2/8hkaEgEyd/vysvNQvGk+QhysXpJW5ve6Q=="], + "@astrojs/mdx": ["@astrojs/mdx@5.0.2", "", { "dependencies": { "@astrojs/markdown-remark": "7.0.1", "@mdx-js/mdx": "^3.1.1", "acorn": "^8.16.0", "es-module-lexer": "^2.0.0", "estree-util-visit": "^2.0.0", "hast-util-to-html": "^9.0.5", "piccolore": "^0.1.3", "rehype-raw": "^7.0.0", "remark-gfm": "^4.0.1", "remark-smartypants": "^3.0.2", "source-map": "^0.7.6", "unist-util-visit": "^5.1.0", "vfile": "^6.0.3" }, "peerDependencies": { "astro": "^6.0.0" } }, "sha512-0as6odPH9ZQhS3pdH9dWmVOwgXuDtytJiE4VvYgR0lSFBvF4PSTyE0HdODHm/d7dBghvWTPc2bQaBm4y4nTBNw=="], - "@astrojs/prism": ["@astrojs/prism@3.3.0", "", { "dependencies": { "prismjs": "^1.30.0" } }, "sha512-q8VwfU/fDZNoDOf+r7jUnMC2//H2l0TuQ6FkGJL8vD8nw/q5KiL3DS1KKBI3QhI9UQhpJ5dc7AtqfbXWuOgLCQ=="], + "@astrojs/prism": ["@astrojs/prism@4.0.1", "", { "dependencies": { "prismjs": "^1.30.0" } }, "sha512-nksZQVjlferuWzhPsBpQ1JE5XuKAf1id1/9Hj4a9KG4+ofrlzxUUwX4YGQF/SuDiuiGKEnzopGOt38F3AnVWsQ=="], - "@astrojs/react": ["@astrojs/react@4.4.2", "", { "dependencies": { "@vitejs/plugin-react": "^4.7.0", "ultrahtml": "^1.6.0", "vite": "^6.4.1" }, "peerDependencies": { "@types/react": "^17.0.50 || ^18.0.21 || ^19.0.0", "@types/react-dom": "^17.0.17 || ^18.0.6 || ^19.0.0", "react": "^17.0.2 || ^18.0.0 || ^19.0.0", "react-dom": "^17.0.2 || ^18.0.0 || ^19.0.0" } }, "sha512-1tl95bpGfuaDMDn8O3x/5Dxii1HPvzjvpL2YTuqOOrQehs60I2DKiDgh1jrKc7G8lv+LQT5H15V6QONQ+9waeQ=="], + "@astrojs/react": ["@astrojs/react@5.0.1", "", { "dependencies": { "@astrojs/internal-helpers": "0.8.0", "@vitejs/plugin-react": "^5.1.4", "devalue": "^5.6.3", "ultrahtml": "^1.6.0", "vite": "^7.3.1" }, "peerDependencies": { "@types/react": "^17.0.50 || ^18.0.21 || ^19.0.0", "@types/react-dom": "^17.0.17 || ^18.0.6 || ^19.0.0", "react": "^17.0.2 || ^18.0.0 || ^19.0.0", "react-dom": "^17.0.2 || ^18.0.0 || ^19.0.0" } }, "sha512-gJgQfDUxyePk+UIzwCEtAq04SGbziwRNwOMYvkxLHEtZScSMvRnvQhDWAEMCjLwwEomoT92Tfm34xpD7XAAzOg=="], - "@astrojs/sitemap": ["@astrojs/sitemap@3.7.0", "", { "dependencies": { "sitemap": "^8.0.2", "stream-replace-string": "^2.0.0", "zod": "^3.25.76" } }, "sha512-+qxjUrz6Jcgh+D5VE1gKUJTA3pSthuPHe6Ao5JCxok794Lewx8hBFaWHtOnN0ntb2lfOf7gvOi9TefUswQ/ZVA=="], + "@astrojs/sitemap": ["@astrojs/sitemap@3.7.1", "", { "dependencies": { "sitemap": "^9.0.0", "stream-replace-string": "^2.0.0", "zod": "^4.3.6" } }, "sha512-IzQqdTeskaMX+QDZCzMuJIp8A8C1vgzMBp/NmHNnadepHYNHcxQdGLQZYfkbd2EbRXUfOS+UDIKx8sKg0oWVdw=="], "@astrojs/telemetry": ["@astrojs/telemetry@3.3.0", "", { "dependencies": { "ci-info": "^4.2.0", "debug": "^4.4.0", "dlv": "^1.1.3", "dset": "^3.1.4", "is-docker": "^3.0.0", "is-wsl": "^3.1.0", "which-pm-runs": "^1.1.0" } }, "sha512-UFBgfeldP06qu6khs/yY+q1cDAaArM2/7AEIqQ9Cuvf7B1hNLq0xDrZkct+QoIGyjq56y8IaE2I3CTvG99mlhQ=="], @@ -192,6 +194,10 @@ "@floating-ui/vue": ["@floating-ui/vue@1.1.11", "", { "dependencies": { "@floating-ui/dom": "^1.7.6", "@floating-ui/utils": "^0.2.11", "vue-demi": ">=0.13.0" } }, "sha512-HzHKCNVxnGS35r9fCHBc3+uCnjw9IWIlCPL683cGgM9Kgj2BiAl8x1mS7vtvP6F9S/e/q4O6MApwSHj8hNLGfw=="], + "@fontsource/ibm-plex-mono": ["@fontsource/ibm-plex-mono@5.2.7", "", {}, "sha512-MKAb8qV+CaiMQn2B0dIi1OV3565NYzp3WN5b4oT6LTkk+F0jR6j0ZN+5BKJiIhffDC3rtBULsYZE65+0018z9w=="], + + "@fontsource/ibm-plex-sans": ["@fontsource/ibm-plex-sans@5.2.8", "", {}, "sha512-eztSXjDhPhcpxNIiGTgMebdLP9qS4rWkysuE1V7c+DjOR0qiezaiDaTwQE7bTnG5HxAY/8M43XKDvs3cYq6ZYQ=="], + "@fontsource/inter": ["@fontsource/inter@5.2.8", "", {}, "sha512-P6r5WnJoKiNVV+zvW2xM13gNdFhAEpQ9dQJHt3naLvfg+LkF2ldgSLiF4T41lf1SQCM9QmkqPTn4TH568IRagg=="], "@fontsource/prompt": ["@fontsource/prompt@5.2.8", "", {}, "sha512-/ocBE0NMMgfzKXcwTsKDJOppc3UA7dBGl127b9uhNzqUlP0720FCSuUXEp2iJb7uC/jnfHW1da7oZtAHDv3whg=="], @@ -474,7 +480,7 @@ "@remirror/core-constants": ["@remirror/core-constants@3.0.0", "", {}, "sha512-42aWfPrimMfDKDi4YegyS7x+/0tlzaqwPQCULLanv3DMIlu96KTJR0fM5isWX2UViOqlGnX6YFgqWepcX+XMNg=="], - "@rolldown/pluginutils": ["@rolldown/pluginutils@1.0.0-beta.27", "", {}, "sha512-+d0F4MKMCbeVUJwG96uQ4SgAznZNSq93I3V+9NHA4OpvqG8mRCpGdKmK8l/dl02h2CCDHwW2FqilnTyDcAnqjA=="], + "@rolldown/pluginutils": ["@rolldown/pluginutils@1.0.0-rc.3", "", {}, "sha512-eybk3TjzzzV97Dlj5c+XrBFW57eTNhzod66y9HrBlzJ6NsCrWCp/2kaPS3K9wJmurBC0Tdw4yPjXKZqlznim3Q=="], "@rollup/pluginutils": ["@rollup/pluginutils@5.3.0", "", { "dependencies": { "@types/estree": "^1.0.0", "estree-walker": "^2.0.2", "picomatch": "^4.0.2" }, "peerDependencies": { "rollup": "^1.20.0||^2.0.0||^3.0.0||^4.0.0" }, "optionalPeers": ["rollup"] }, "sha512-5EdhGZtnu3V88ces7s53hhfK5KSASnJZv8Lulpc04cWO3REESroJXg73DFsOmgbU2BhwV0E20bu2IDZb3VKW4Q=="], @@ -544,17 +550,19 @@ "@sentry/utils": ["@sentry/utils@7.120.4", "", { "dependencies": { "@sentry/types": "7.120.4" } }, "sha512-zCKpyDIWKHwtervNK2ZlaK8mMV7gVUijAgFeJStH+CU/imcdquizV3pFLlSQYRswG+Lbyd6CT/LGRh3IbtkCFw=="], - "@shikijs/core": ["@shikijs/core@3.23.0", "", { "dependencies": { "@shikijs/types": "3.23.0", "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4", "hast-util-to-html": "^9.0.5" } }, "sha512-NSWQz0riNb67xthdm5br6lAkvpDJRTgB36fxlo37ZzM2yq0PQFFzbd8psqC2XMPgCzo1fW6cVi18+ArJ44wqgA=="], + "@shikijs/core": ["@shikijs/core@4.0.2", "", { "dependencies": { "@shikijs/primitive": "4.0.2", "@shikijs/types": "4.0.2", "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4", "hast-util-to-html": "^9.0.5" } }, "sha512-hxT0YF4ExEqB8G/qFdtJvpmHXBYJ2lWW7qTHDarVkIudPFE6iCIrqdgWxGn5s+ppkGXI0aEGlibI0PAyzP3zlw=="], - "@shikijs/engine-javascript": ["@shikijs/engine-javascript@3.23.0", "", { "dependencies": { "@shikijs/types": "3.23.0", "@shikijs/vscode-textmate": "^10.0.2", "oniguruma-to-es": "^4.3.4" } }, "sha512-aHt9eiGFobmWR5uqJUViySI1bHMqrAgamWE1TYSUoftkAeCCAiGawPMwM+VCadylQtF4V3VNOZ5LmfItH5f3yA=="], + "@shikijs/engine-javascript": ["@shikijs/engine-javascript@4.0.2", "", { "dependencies": { "@shikijs/types": "4.0.2", "@shikijs/vscode-textmate": "^10.0.2", "oniguruma-to-es": "^4.3.4" } }, "sha512-7PW0Nm49DcoUIQEXlJhNNBHyoGMjalRETTCcjMqEaMoJRLljy1Bi/EGV3/qLBgLKQejdspiiYuHGQW6dX94Nag=="], - "@shikijs/engine-oniguruma": ["@shikijs/engine-oniguruma@3.23.0", "", { "dependencies": { "@shikijs/types": "3.23.0", "@shikijs/vscode-textmate": "^10.0.2" } }, "sha512-1nWINwKXxKKLqPibT5f4pAFLej9oZzQTsby8942OTlsJzOBZ0MWKiwzMsd+jhzu8YPCHAswGnnN1YtQfirL35g=="], + "@shikijs/engine-oniguruma": ["@shikijs/engine-oniguruma@4.0.2", "", { "dependencies": { "@shikijs/types": "4.0.2", "@shikijs/vscode-textmate": "^10.0.2" } }, "sha512-UpCB9Y2sUKlS9z8juFSKz7ZtysmeXCgnRF0dlhXBkmQnek7lAToPte8DkxmEYGNTMii72zU/lyXiCB6StuZeJg=="], - "@shikijs/langs": ["@shikijs/langs@3.23.0", "", { "dependencies": { "@shikijs/types": "3.23.0" } }, "sha512-2Ep4W3Re5aB1/62RSYQInK9mM3HsLeB91cHqznAJMuylqjzNVAVCMnNWRHFtcNHXsoNRayP9z1qj4Sq3nMqYXg=="], + "@shikijs/langs": ["@shikijs/langs@4.0.2", "", { "dependencies": { "@shikijs/types": "4.0.2" } }, "sha512-KaXby5dvoeuZzN0rYQiPMjFoUrz4hgwIE+D6Du9owcHcl6/g16/yT5BQxSW5cGt2MZBz6Hl0YuRqf12omRfUUg=="], - "@shikijs/themes": ["@shikijs/themes@3.23.0", "", { "dependencies": { "@shikijs/types": "3.23.0" } }, "sha512-5qySYa1ZgAT18HR/ypENL9cUSGOeI2x+4IvYJu4JgVJdizn6kG4ia5Q1jDEOi7gTbN4RbuYtmHh0W3eccOrjMA=="], + "@shikijs/primitive": ["@shikijs/primitive@4.0.2", "", { "dependencies": { "@shikijs/types": "4.0.2", "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4" } }, "sha512-M6UMPrSa3fN5ayeJwFVl9qWofl273wtK1VG8ySDZ1mQBfhCpdd8nEx7nPZ/tk7k+TYcpqBZzj/AnwxT9lO+HJw=="], - "@shikijs/types": ["@shikijs/types@3.23.0", "", { "dependencies": { "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4" } }, "sha512-3JZ5HXOZfYjsYSk0yPwBrkupyYSLpAE26Qc0HLghhZNGTZg/SKxXIIgoxOpmmeQP0RRSDJTk1/vPfw9tbw+jSQ=="], + "@shikijs/themes": ["@shikijs/themes@4.0.2", "", { "dependencies": { "@shikijs/types": "4.0.2" } }, "sha512-mjCafwt8lJJaVSsQvNVrJumbnnj1RI8jbUKrPKgE6E3OvQKxnuRoBaYC51H4IGHePsGN/QtALglWBU7DoKDFnA=="], + + "@shikijs/types": ["@shikijs/types@4.0.2", "", { "dependencies": { "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4" } }, "sha512-qzbeRooUTPnLE+sHD/Z8DStmaDgnbbc/pMrU203950aRqjX/6AFHeDYT+j00y2lPdz0ywJKx7o/7qnqTivtlXg=="], "@shikijs/vscode-textmate": ["@shikijs/vscode-textmate@10.0.2", "", {}, "sha512-83yeghZ2xxin3Nj8z1NMd/NCuca+gsYXswywDy5bHvwlWL8tpTQmzGeUuHd9FC3E/SBEMvzJRwWEOz5gGes9Qg=="], @@ -730,7 +738,7 @@ "@types/nlcst": ["@types/nlcst@2.0.3", "", { "dependencies": { "@types/unist": "*" } }, "sha512-vSYNSDe6Ix3q+6Z7ri9lyWqgGhJTmzRjZRqyq15N0Z/1/UnVsno9G/N40NBijoYx2seFDIl0+B2mgAb9mezUCA=="], - "@types/node": ["@types/node@17.0.45", "", {}, "sha512-w+tIMs3rq2afQdsPJlODhoUEKzFP1ayaoyl1CcnwtIlsVe7K7bA1NGm4s3PraqTLlXnbIN84zuBlxBWo1u9BLw=="], + "@types/node": ["@types/node@24.12.0", "", { "dependencies": { "undici-types": "~7.16.0" } }, "sha512-GYDxsZi3ChgmckRT9HPU0WEhKLP08ev/Yfcq2AstjrDASOYCSXeyjDsHg4v5t4jOj7cyDX3vmprafKlWIG9MXQ=="], "@types/pg": ["@types/pg@8.6.1", "", { "dependencies": { "@types/node": "*", "pg-protocol": "*", "pg-types": "^2.2.0" } }, "sha512-1Kc4oAGzAl7uqUStZCDvaLFqZrW9qWSjXOmBfdgyBP5La7Us6Mg4GBvRlSoaZMhQF/zSj1C8CtKMBkoiT8eL8w=="], @@ -764,7 +772,7 @@ "@unlighthouse/server": ["@unlighthouse/server@0.17.7", "", { "dependencies": { "@unlighthouse/core": "0.17.7", "h3": "^1.15.5", "listhen": "^1.9.0" } }, "sha512-r4mF3HBZ3fkfQQR6SrY4aLn42N5HfUPhc9qzSb40b7KZxny/HSwfJGA8vu9tfoZ7y5r2+2uA8UO1NmGzkfBEpg=="], - "@vitejs/plugin-react": ["@vitejs/plugin-react@4.7.0", "", { "dependencies": { "@babel/core": "^7.28.0", "@babel/plugin-transform-react-jsx-self": "^7.27.1", "@babel/plugin-transform-react-jsx-source": "^7.27.1", "@rolldown/pluginutils": "1.0.0-beta.27", "@types/babel__core": "^7.20.5", "react-refresh": "^0.17.0" }, "peerDependencies": { "vite": "^4.2.0 || ^5.0.0 || ^6.0.0 || ^7.0.0" } }, "sha512-gUu9hwfWvvEDBBmgtAowQCojwZmJ5mcLn3aufeCsitijs3+f2NsrPtlAWIR6OPiqljl96GVCUbLe0HyqIpVaoA=="], + "@vitejs/plugin-react": ["@vitejs/plugin-react@5.2.0", "", { "dependencies": { "@babel/core": "^7.29.0", "@babel/plugin-transform-react-jsx-self": "^7.27.1", "@babel/plugin-transform-react-jsx-source": "^7.27.1", "@rolldown/pluginutils": "1.0.0-rc.3", "@types/babel__core": "^7.20.5", "react-refresh": "^0.18.0" }, "peerDependencies": { "vite": "^4.2.0 || ^5.0.0 || ^6.0.0 || ^7.0.0 || ^8.0.0" } }, "sha512-YmKkfhOAi3wsB1PhJq5Scj3GXMn3WvtQ/JC0xoopuHoXSdmtdStOpFrYaT1kie2YgFBcIe64ROzMYRjCrYOdYw=="], "@volar/kit": ["@volar/kit@2.4.28", "", { "dependencies": { "@volar/language-service": "2.4.28", "@volar/typescript": "2.4.28", "typesafe-path": "^0.2.2", "vscode-languageserver-textdocument": "^1.0.11", "vscode-uri": "^3.0.8" }, "peerDependencies": { "typescript": "*" } }, "sha512-cKX4vK9dtZvDRaAzeoUdaAJEew6IdxHNCRrdp5Kvcl6zZOqb6jTOfk3kXkIkG3T7oTFXguEMt5+9ptyqYR84Pg=="], @@ -844,7 +852,7 @@ "astring": ["astring@1.9.0", "", { "bin": { "astring": "bin/astring" } }, "sha512-LElXdjswlqjWrPpJFg1Fx4wpkOCxj1TDHlSV4PlaRxHGWko024xICaa97ZkMfs6DRKlCguiAI+rbXv5GWwXIkg=="], - "astro": ["astro@5.18.0", "", { "dependencies": { "@astrojs/compiler": "^2.13.0", "@astrojs/internal-helpers": "0.7.5", "@astrojs/markdown-remark": "6.3.10", "@astrojs/telemetry": "3.3.0", "@capsizecss/unpack": "^4.0.0", "@oslojs/encoding": "^1.1.0", "@rollup/pluginutils": "^5.3.0", "acorn": "^8.15.0", "aria-query": "^5.3.2", "axobject-query": "^4.1.0", "boxen": "8.0.1", "ci-info": "^4.3.1", "clsx": "^2.1.1", "common-ancestor-path": "^1.0.1", "cookie": "^1.1.1", "cssesc": "^3.0.0", "debug": "^4.4.3", "deterministic-object-hash": "^2.0.2", "devalue": "^5.6.2", "diff": "^8.0.3", "dlv": "^1.1.3", "dset": "^3.1.4", "es-module-lexer": "^1.7.0", "esbuild": "^0.27.3", "estree-walker": "^3.0.3", "flattie": "^1.1.1", "fontace": "~0.4.0", "github-slugger": "^2.0.0", "html-escaper": "3.0.3", "http-cache-semantics": "^4.2.0", "import-meta-resolve": "^4.2.0", "js-yaml": "^4.1.1", "magic-string": "^0.30.21", "magicast": "^0.5.1", "mrmime": "^2.0.1", "neotraverse": "^0.6.18", "p-limit": "^6.2.0", "p-queue": "^8.1.1", "package-manager-detector": "^1.6.0", "piccolore": "^0.1.3", "picomatch": "^4.0.3", "prompts": "^2.4.2", "rehype": "^13.0.2", "semver": "^7.7.3", "shiki": "^3.21.0", "smol-toml": "^1.6.0", "svgo": "^4.0.0", "tinyexec": "^1.0.2", "tinyglobby": "^0.2.15", "tsconfck": "^3.1.6", "ultrahtml": "^1.6.0", "unifont": "~0.7.3", "unist-util-visit": "^5.0.0", "unstorage": "^1.17.4", "vfile": "^6.0.3", "vite": "^6.4.1", "vitefu": "^1.1.1", "xxhash-wasm": "^1.1.0", "yargs-parser": "^21.1.1", "yocto-spinner": "^0.2.3", "zod": "^3.25.76", "zod-to-json-schema": "^3.25.1", "zod-to-ts": "^1.2.0" }, "optionalDependencies": { "sharp": "^0.34.0" }, "bin": { "astro": "astro.js" } }, "sha512-CHiohwJIS4L0G6/IzE1Fx3dgWqXBCXus/od0eGUfxrZJD2um2pE7ehclMmgL/fXqbU7NfE1Ze2pq34h2QaA6iQ=="], + "astro": ["astro@6.0.7", "", { "dependencies": { "@astrojs/compiler": "^3.0.0", "@astrojs/internal-helpers": "0.8.0", "@astrojs/markdown-remark": "7.0.1", "@astrojs/telemetry": "3.3.0", "@capsizecss/unpack": "^4.0.0", "@clack/prompts": "^1.0.1", "@oslojs/encoding": "^1.1.0", "@rollup/pluginutils": "^5.3.0", "aria-query": "^5.3.2", "axobject-query": "^4.1.0", "ci-info": "^4.4.0", "clsx": "^2.1.1", "common-ancestor-path": "^2.0.0", "cookie": "^1.1.1", "devalue": "^5.6.3", "diff": "^8.0.3", "dlv": "^1.1.3", "dset": "^3.1.4", "es-module-lexer": "^2.0.0", "esbuild": "^0.27.3", "flattie": "^1.1.1", "fontace": "~0.4.1", "github-slugger": "^2.0.0", "html-escaper": "3.0.3", "http-cache-semantics": "^4.2.0", "js-yaml": "^4.1.1", "magic-string": "^0.30.21", "magicast": "^0.5.2", "mrmime": "^2.0.1", "neotraverse": "^0.6.18", "obug": "^2.1.1", "p-limit": "^7.3.0", "p-queue": "^9.1.0", "package-manager-detector": "^1.6.0", "piccolore": "^0.1.3", "picomatch": "^4.0.3", "rehype": "^13.0.2", "semver": "^7.7.4", "shiki": "^4.0.0", "smol-toml": "^1.6.0", "svgo": "^4.0.0", "tinyclip": "^0.1.6", "tinyexec": "^1.0.2", "tinyglobby": "^0.2.15", "tsconfck": "^3.1.6", "ultrahtml": "^1.6.0", "unifont": "~0.7.4", "unist-util-visit": "^5.1.0", "unstorage": "^1.17.4", "vfile": "^6.0.3", "vite": "^7.3.1", "vitefu": "^1.1.2", "xxhash-wasm": "^1.1.0", "yargs-parser": "^22.0.0", "zod": "^4.3.6" }, "optionalDependencies": { "sharp": "^0.34.0" }, "bin": { "astro": "bin/astro.mjs" } }, "sha512-tCUrtQI+2Dk13xTM07JYrvk16T4ekWqSXh0/dVCunne816ZV+RCs1tomSoTHZi3DJdoaTnLJmkH+uxCC3b1KWw=="], "astro-seo": ["astro-seo@0.8.4", "", { "dependencies": { "@astrojs/check": "^0.5.4" } }, "sha512-Ou1vzQSXAxa0K8rtNtXNvSpYqOGEgMhh0immMxJeXmbVZac3UKCNWAoXWyOQDFYsZvBugCRSg0N1phBqPMVgCw=="], @@ -972,7 +980,7 @@ "commander": ["commander@14.0.2", "", {}, "sha512-TywoWNNRbhoD0BXs1P3ZEScW8W5iKrnbithIl0YH+uCmBd0QpPOA8yc82DS3BIE5Ma6FnBVUsJ7wVUDz4dvOWQ=="], - "common-ancestor-path": ["common-ancestor-path@1.0.1", "", {}, "sha512-L3sHRo1pXXEqX8VU28kfgUY+YGsk09hPqZiZmLacNib6XNTCM8ubYeT7ryXQw8asB1sKgcU5lkB7ONug08aB8w=="], + "common-ancestor-path": ["common-ancestor-path@2.0.0", "", {}, "sha512-dnN3ibLeoRf2HNC+OlCiNc5d2zxbLJXOtiZUudNFSXZrNSydxcCsSpRzXwfu7BBWCIfHPw+xTayeBvJCP/D8Ng=="], "confbox": ["confbox@0.2.4", "", {}, "sha512-ysOGlgTFbN2/Y6Cg3Iye8YKulHw+R2fNXHrgSmXISQdMnomY6eNDprVdW9R5xBguEqI954+S6709UyiO7B+6OQ=="], @@ -1094,7 +1102,7 @@ "emmet": ["emmet@2.4.11", "", { "dependencies": { "@emmetio/abbreviation": "^2.3.3", "@emmetio/css-abbreviation": "^2.1.8" } }, "sha512-23QPJB3moh/U9sT4rQzGgeyyGIrcM+GH5uVYg2C6wZIxAIJq7Ng3QLT79tl8FUwDXhyq9SusfknOrofAKqvgyQ=="], - "emoji-regex": ["emoji-regex@10.6.0", "", {}, "sha512-toUI84YS5YmxW219erniWD0CIVOo46xGKColeNQRgOzDorgBi1v4D71/OFzgD9GO2UGKIv1C3Sp8DAn0+j5w7A=="], + "emoji-regex": ["emoji-regex@8.0.0", "", {}, "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A=="], "end-of-stream": ["end-of-stream@1.4.5", "", { "dependencies": { "once": "^1.4.0" } }, "sha512-ooEGc6HP26xXq/N+GCGOT0JKCLDGrq2bQUZrQ7gyrJiZANJ/8YDTxTpQBXGMn+WbIQXNVpyWymm7KYVICQnyOg=="], @@ -1114,7 +1122,7 @@ "es-errors": ["es-errors@1.3.0", "", {}, "sha512-Zf5H2Kxt2xjTvbJvP2ZWLEICxA6j+hAmMzIlypy4xcBg1vKVnx89Wy0GbS+kf5cwCVFFzdCFh2XSCFNULS6csw=="], - "es-module-lexer": ["es-module-lexer@1.7.0", "", {}, "sha512-jEQoCwk8hyb2AZziIOLhDqpm5+2ww5uIE6lkO/6jcOCusfk6LhMHpXXfBLXTZ7Ydyt0j4VoUQv6uGNYbdW+kBA=="], + "es-module-lexer": ["es-module-lexer@2.0.0", "", {}, "sha512-5POEcUuZybH7IdmGsD8wlf0AI55wMecM9rVBTI/qEAy2c1kTOm3DjFYjrBdI2K3BaJjJYfYFeRtM0t9ssnRuxw=="], "es-object-atoms": ["es-object-atoms@1.1.1", "", { "dependencies": { "es-errors": "^1.3.0" } }, "sha512-FGgH2h8zKNim9ljj7dankFPcICIK9Cp5bm+c2gQSYePhpaG5+esrLODihIorn+Pe6FGJzWhXQotPv73jTaldXA=="], @@ -1688,11 +1696,11 @@ "p-cancelable": ["p-cancelable@3.0.0", "", {}, "sha512-mlVgR3PGuzlo0MmTdk4cXqXWlwQDLnONTAg6sm62XkMJEiRxN3GL3SffkYvqwonbkJBcrI7Uvv5Zh9yjvn2iUw=="], - "p-limit": ["p-limit@6.2.0", "", { "dependencies": { "yocto-queue": "^1.1.1" } }, "sha512-kuUqqHNUqoIWp/c467RI4X6mmyuojY5jGutNU0wVTmEOOfcuwLqyMVoAi9MKi2Ak+5i9+nhmrK4ufZE8069kHA=="], + "p-limit": ["p-limit@7.3.0", "", { "dependencies": { "yocto-queue": "^1.2.1" } }, "sha512-7cIXg/Z0M5WZRblrsOla88S4wAK+zOQQWeBYfV3qJuJXMr+LnbYjaadrFaS0JILfEDPVqHyKnZ1Z/1d6J9VVUw=="], - "p-queue": ["p-queue@8.1.1", "", { "dependencies": { "eventemitter3": "^5.0.1", "p-timeout": "^6.1.2" } }, "sha512-aNZ+VfjobsWryoiPnEApGGmf5WmNsCo9xu8dfaYamG5qaLP7ClhLN6NgsFe6SwJ2UbLEBK5dv9x8Mn5+RVhMWQ=="], + "p-queue": ["p-queue@9.1.0", "", { "dependencies": { "eventemitter3": "^5.0.1", "p-timeout": "^7.0.0" } }, "sha512-O/ZPaXuQV29uSLbxWBGGZO1mCQXV2BLIwUr59JUU9SoH76mnYvtms7aafH/isNSNGwuEfP6W/4xD0/TJXxrizw=="], - "p-timeout": ["p-timeout@6.1.4", "", {}, "sha512-MyIV3ZA/PmyBN/ud8vV9XzwTrNtR4jFrObymZYnZqMmW0zA8Z17vnT0rBgFE/TlohB+YCHqXMgZzb3Csp49vqg=="], + "p-timeout": ["p-timeout@7.0.1", "", {}, "sha512-AxTM2wDGORHGEkPCt8yqxOTMgpfbEHqF51f/5fJCmwFC3C/zNcGT63SymH2ttOAaiIws2zVg4+izQCjrakcwHg=="], "pac-proxy-agent": ["pac-proxy-agent@7.2.0", "", { "dependencies": { "@tootallnate/quickjs-emscripten": "^0.23.0", "agent-base": "^7.1.2", "debug": "^4.3.4", "get-uri": "^6.0.1", "http-proxy-agent": "^7.0.0", "https-proxy-agent": "^7.0.6", "pac-resolver": "^7.0.1", "socks-proxy-agent": "^8.0.5" } }, "sha512-TEB8ESquiLMc0lV8vcd5Ql/JAKAoyzHFXaStwjkzpOpC5Yv+pIzLfHvjTSdf3vpa2bMiUQrg9i6276yn8666aA=="], @@ -1832,7 +1840,7 @@ "react-dom": ["react-dom@19.2.4", "", { "dependencies": { "scheduler": "^0.27.0" }, "peerDependencies": { "react": "^19.2.4" } }, "sha512-AXJdLo8kgMbimY95O2aKQqsz2iWi9jMgKJhRBAxECE4IFxfcazB2LmzloIoibJI3C12IlY20+KFaLv+71bUJeQ=="], - "react-refresh": ["react-refresh@0.17.0", "", {}, "sha512-z6F7K9bV85EfseRCp2bzrpyQ0Gkw1uLoCel9XBVWPg/TjRj94SkJzUTGfOa4bs7iJvBWtQG0Wq7wnI0syw3EBQ=="], + "react-refresh": ["react-refresh@0.18.0", "", {}, "sha512-QgT5//D3jfjJb6Gsjxv0Slpj23ip+HtOpnNgnb2S5zU3CB26G/IDPGoy4RJB42wzFE46DRsstbW6tKHoKbhAxw=="], "react-remove-scroll": ["react-remove-scroll@2.7.2", "", { "dependencies": { "react-remove-scroll-bar": "^2.3.7", "react-style-singleton": "^2.2.3", "tslib": "^2.1.0", "use-callback-ref": "^1.3.3", "use-sidecar": "^1.1.3" }, "peerDependencies": { "@types/react": "*", "react": "^16.8.0 || ^17.0.0 || ^18.0.0 || ^19.0.0 || ^19.0.0-rc" }, "optionalPeers": ["@types/react"] }, "sha512-Iqb9NjCCTt6Hf+vOdNIZGdTiH1QSqr27H/Ek9sv/a97gfueI/5h1s3yRi1nngzMUaOOToin5dI1dXKdXiF+u0Q=="], @@ -1944,7 +1952,7 @@ "shell-quote": ["shell-quote@1.8.3", "", {}, "sha512-ObmnIF4hXNg1BqhnHmgbDETF8dLPCggZWBjkQfhZpbszZnYur5DUljTcCHii5LC3J5E0yeO/1LIMyH+UvHQgyw=="], - "shiki": ["shiki@3.23.0", "", { "dependencies": { "@shikijs/core": "3.23.0", "@shikijs/engine-javascript": "3.23.0", "@shikijs/engine-oniguruma": "3.23.0", "@shikijs/langs": "3.23.0", "@shikijs/themes": "3.23.0", "@shikijs/types": "3.23.0", "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4" } }, "sha512-55Dj73uq9ZXL5zyeRPzHQsK7Nbyt6Y10k5s7OjuFZGMhpp4r/rsLBH0o/0fstIzX1Lep9VxefWljK/SKCzygIA=="], + "shiki": ["shiki@4.0.2", "", { "dependencies": { "@shikijs/core": "4.0.2", "@shikijs/engine-javascript": "4.0.2", "@shikijs/engine-oniguruma": "4.0.2", "@shikijs/langs": "4.0.2", "@shikijs/themes": "4.0.2", "@shikijs/types": "4.0.2", "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4" } }, "sha512-eAVKTMedR5ckPo4xne/PjYQYrU3qx78gtJZ+sHlXEg5IHhhoQhMfZVzetTYuaJS0L2Ef3AcCRzCHV8T0WI6nIQ=="], "shimmer": ["shimmer@1.2.1", "", {}, "sha512-sQTKC1Re/rM6XyFM6fIAGHRPVGvyXfgzIDvzoq608vM+jeyVD0Tu1E6Np0Kc2zAIFWIj963V2800iF/9LPieQw=="], @@ -1954,7 +1962,7 @@ "sisteransi": ["sisteransi@1.0.5", "", {}, "sha512-bLGGlR1QxBcynn2d5YmDX4MGjlZvy2MRBDRNHLJ8VI6l6+9FUiyTFNJ0IveOSP0bcXgVDPRcfGqA0pjaqUpfVg=="], - "sitemap": ["sitemap@8.0.3", "", { "dependencies": { "@types/node": "^17.0.5", "@types/sax": "^1.2.1", "arg": "^5.0.0", "sax": "^1.4.1" }, "bin": { "sitemap": "dist/cli.js" } }, "sha512-9Ew1tR2WYw8RGE2XLy7GjkusvYXy8Rg6y8TYuBuQMfIEdGcWoJpY2Wr5DzsEiL/TKCw56+YKTCCUHglorEYK+A=="], + "sitemap": ["sitemap@9.0.1", "", { "dependencies": { "@types/node": "^24.9.2", "@types/sax": "^1.2.1", "arg": "^5.0.0", "sax": "^1.4.1" }, "bin": { "sitemap": "dist/esm/cli.js" } }, "sha512-S6hzjGJSG3d6if0YoF5kTyeRJvia6FSTBroE5fQ0bu1QNxyJqhhinfUsXi9fH3MgtXODWvwo2BDyQSnhPQ88uQ=="], "sitemapper": ["sitemapper@4.1.4", "", { "dependencies": { "fast-xml-parser": "^5.3.5", "got": "^13.0.0", "p-limit": "^6.2.0" }, "bin": { "sitemapper": "bin/sitemapper.js" } }, "sha512-eY7Rczd/X4LizpL6T1+iYVuVEsYU1Be+Q17d9ZyeWHZ1tIIzjkHzI/I4cBQKJJHCOyEctvWgYDp/U5cDWJ32IQ=="], @@ -1986,7 +1994,7 @@ "streamx": ["streamx@2.23.0", "", { "dependencies": { "events-universal": "^1.0.0", "fast-fifo": "^1.3.2", "text-decoder": "^1.1.0" } }, "sha512-kn+e44esVfn2Fa/O0CPFcex27fjIL6MkVae0Mm6q+E6f0hWv578YCERbv+4m02cjxvDsPKLnmxral/rR6lBMAg=="], - "string-width": ["string-width@7.2.0", "", { "dependencies": { "emoji-regex": "^10.3.0", "get-east-asian-width": "^1.0.0", "strip-ansi": "^7.1.0" } }, "sha512-tsaTIkKW9b4N+AEj+SVA+WhJzV7/zMhcSu78mLKWSk7cXMOSHsBKFWUs0fWwq8QyK3MgJBQRX6Gbi4kYbdvGkQ=="], + "string-width": ["string-width@4.2.3", "", { "dependencies": { "emoji-regex": "^8.0.0", "is-fullwidth-code-point": "^3.0.0", "strip-ansi": "^6.0.1" } }, "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g=="], "stringify-entities": ["stringify-entities@4.0.4", "", { "dependencies": { "character-entities-html4": "^2.0.0", "character-entities-legacy": "^3.0.0" } }, "sha512-IwfBptatlO+QCJUo19AqvrPNqlVMpW9YEL2LIVY+Rpv2qsjCGxaDLNRgeGsQWJhfItebuJhsGSLjaBbNSQ+ieg=="], @@ -2036,6 +2044,8 @@ "tiny-inflate": ["tiny-inflate@1.0.3", "", {}, "sha512-pkY1fj1cKHb2seWDy0B16HeWyczlJA9/WW3u3c4z/NiWDsO3DOU5D7nhTLE9CF0yXv/QZFY7sEJmj24dK+Rrqw=="], + "tinyclip": ["tinyclip@0.1.12", "", {}, "sha512-Ae3OVUqifDw0wBriIBS7yVaW44Dp6eSHQcyq4Igc7eN2TJH/2YsicswaW+J/OuMvhpDPOKEgpAZCjkb4hpoyeA=="], + "tinyexec": ["tinyexec@1.0.2", "", {}, "sha512-W/KYk+NFhkmsYpuHq5JykngiOCnxeVL8v8dFnqxSD8qEEdRfXk1SDM6JzNqcERbcGYj9tMrDQBYV9cjgnunFIg=="], "tinyglobby": ["tinyglobby@0.2.15", "", { "dependencies": { "fdir": "^6.5.0", "picomatch": "^4.0.3" } }, "sha512-j2Zq4NyQYG5XMST4cbs02Ak8iJUdxRM0XI5QyxXuZOzKOINmWurp3smXu3y5wDcJrptwpSjgXHzIQxR0omXljQ=="], @@ -2162,7 +2172,7 @@ "vfile-message": ["vfile-message@4.0.3", "", { "dependencies": { "@types/unist": "^3.0.0", "unist-util-stringify-position": "^4.0.0" } }, "sha512-QTHzsGd1EhbZs4AsQ20JX1rC3cOlt/IWJruk893DfLRr57lcnOeMaWG4K0JrRta4mIJZKth2Au3mM3u03/JWKw=="], - "vite": ["vite@6.4.1", "", { "dependencies": { "esbuild": "^0.25.0", "fdir": "^6.4.4", "picomatch": "^4.0.2", "postcss": "^8.5.3", "rollup": "^4.34.9", "tinyglobby": "^0.2.13" }, "optionalDependencies": { "fsevents": "~2.3.3" }, "peerDependencies": { "@types/node": "^18.0.0 || ^20.0.0 || >=22.0.0", "jiti": ">=1.21.0", "less": "*", "lightningcss": "^1.21.0", "sass": "*", "sass-embedded": "*", "stylus": "*", "sugarss": "*", "terser": "^5.16.0", "tsx": "^4.8.1", "yaml": "^2.4.2" }, "optionalPeers": ["@types/node", "jiti", "less", "lightningcss", "sass", "sass-embedded", "stylus", "sugarss", "terser", "tsx", "yaml"], "bin": { "vite": "bin/vite.js" } }, "sha512-+Oxm7q9hDoLMyJOYfUYBuHQo+dkAloi33apOPP56pzj+vsdJDzr+j1NISE5pyaAuKL4A3UD34qd0lx5+kfKp2g=="], + "vite": ["vite@7.3.1", "", { "dependencies": { "esbuild": "^0.27.0", "fdir": "^6.5.0", "picomatch": "^4.0.3", "postcss": "^8.5.6", "rollup": "^4.43.0", "tinyglobby": "^0.2.15" }, "optionalDependencies": { "fsevents": "~2.3.3" }, "peerDependencies": { "@types/node": "^20.19.0 || >=22.12.0", "jiti": ">=1.21.0", "less": "^4.0.0", "lightningcss": "^1.21.0", "sass": "^1.70.0", "sass-embedded": "^1.70.0", "stylus": ">=0.54.8", "sugarss": "^5.0.0", "terser": "^5.16.0", "tsx": "^4.8.1", "yaml": "^2.4.2" }, "optionalPeers": ["@types/node", "jiti", "less", "lightningcss", "sass", "sass-embedded", "stylus", "sugarss", "terser", "tsx", "yaml"], "bin": { "vite": "bin/vite.js" } }, "sha512-w+N7Hifpc3gRjZ63vYBXA56dvvRlNWRczTdmCBBa+CotUzAPf5b7YMdMR/8CQoeYE5LX3W4wj6RYTgonm1b9DA=="], "vitefu": ["vitefu@1.1.2", "", { "peerDependencies": { "vite": "^3.0.0 || ^4.0.0 || ^5.0.0 || ^6.0.0 || ^7.0.0 || ^8.0.0-beta.0" }, "optionalPeers": ["vite"] }, "sha512-zpKATdUbzbsycPFBN71nS2uzBUQiVnFoOrr2rvqv34S1lcAgMKKkjWleLGeiJlZ8lwCXvtWaRn7R3ZC16SYRuw=="], @@ -2256,7 +2266,7 @@ "yargs": ["yargs@17.7.2", "", { "dependencies": { "cliui": "^8.0.1", "escalade": "^3.1.1", "get-caller-file": "^2.0.5", "require-directory": "^2.1.1", "string-width": "^4.2.3", "y18n": "^5.0.5", "yargs-parser": "^21.1.1" } }, "sha512-7dSzzRQ++CKnNI/krKnYRV7JKKPUXMEh61soaHKg9mrWEhzFWhFnxPxGl+69cD1Ou63C13NUPCnmIcrvqCuM6w=="], - "yargs-parser": ["yargs-parser@21.1.1", "", {}, "sha512-tVpsJW7DdjecAiFpbIB1e3qxIQsE6NoPc5/eTdrbbIC4h0LVsWhnoa3g+m2HclBIujHzsxZ4VJVA+GUuc2/LBw=="], + "yargs-parser": ["yargs-parser@22.0.0", "", {}, "sha512-rwu/ClNdSMpkSrUb+d6BRsSkLUq1fmfsY6TOpYzTwvwkg1/NRG85KBy3kq++A8LKQwX6lsu+aWad+2khvuXrqw=="], "yauzl": ["yauzl@2.10.0", "", { "dependencies": { "buffer-crc32": "~0.2.3", "fd-slicer": "~1.1.0" } }, "sha512-p4a9I6X6nu6IhoGmBqAcbJy1mlC4j27vEPZX9F4L4/vZT3Lyq1VkFHw/V/PUcB9Buo+DG3iHkT0x3Qya58zc3g=="], @@ -2268,7 +2278,7 @@ "yoctocolors": ["yoctocolors@2.1.2", "", {}, "sha512-CzhO+pFNo8ajLM2d2IW/R93ipy99LWjtwblvC1RsoSUMZgyLbYFr221TnSNT7GjGdYui6P459mw9JH/g/zW2ug=="], - "zod": ["zod@3.25.76", "", {}, "sha512-gzUt/qt81nXsFGKIFcC3YnfEAx5NkunCfnDlvuBSSFS02bcXu4Lmea0AFIUwbLWxWPx3d9p8S5QoaujKcNQxcQ=="], + "zod": ["zod@4.3.6", "", {}, "sha512-rftlrkhHZOcjDwkGlnUtZZkvaPHCsDATp4pGpuOOMDaTdDDXF91wuVDJoWoPsKX/3YPQ5fHuF3STjcYyKr+Qhg=="], "zod-to-json-schema": ["zod-to-json-schema@3.25.1", "", { "peerDependencies": { "zod": "^3.25 || ^4" } }, "sha512-pM/SU9d3YAggzi6MtR4h7ruuQlqKtad8e9S0fmxcMi+ueAK5Korys/aWcV9LIIHTVbj01NdzxcnXSN+O74ZIVA=="], @@ -2358,10 +2368,12 @@ "@vue/compiler-sfc/estree-walker": ["estree-walker@2.0.2", "", {}, "sha512-Rfkk/Mp/DL7JVje3u18FxFujQlTNR2q6QfMSMB7AvCBx91NGj/ba3kCfza0f6dVDbw7YlRf/nDrn7pQrCCyQ/w=="], - "ansi-align/string-width": ["string-width@4.2.3", "", { "dependencies": { "emoji-regex": "^8.0.0", "is-fullwidth-code-point": "^3.0.0", "strip-ansi": "^6.0.1" } }, "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g=="], - "anymatch/picomatch": ["picomatch@2.3.1", "", {}, "sha512-JU3teHTNjmE2VCGFzuY8EXzCDVwEqB2a8fsIvwaStHhAWJEeVd1o1QD80CU6+ZdEXXSLbSsuLwJjkCBWqRQUVA=="], + "astro/@astrojs/compiler": ["@astrojs/compiler@3.0.1", "", {}, "sha512-z97oYbdebO5aoWzuJ/8q5hLK232+17KcLZ7cJ8BCWk6+qNzVxn/gftC0KzMBUTD8WAaBkPpNSQK6PXLnNrZ0CA=="], + + "boxen/string-width": ["string-width@7.2.0", "", { "dependencies": { "emoji-regex": "^10.3.0", "get-east-asian-width": "^1.0.0", "strip-ansi": "^7.1.0" } }, "sha512-tsaTIkKW9b4N+AEj+SVA+WhJzV7/zMhcSu78mLKWSk7cXMOSHsBKFWUs0fWwq8QyK3MgJBQRX6Gbi4kYbdvGkQ=="], + "boxen/wrap-ansi": ["wrap-ansi@9.0.2", "", { "dependencies": { "ansi-styles": "^6.2.1", "string-width": "^7.0.0", "strip-ansi": "^7.1.0" } }, "sha512-42AtmgqjV+X1VpdOfyTGOYRi0/zsoLqtXQckTmqTeybT+BDIbM/Guxo7x3pE2vtpr1ok6xRqM9OpBe+Jyoqyww=="], "cacheable-request/get-stream": ["get-stream@6.0.1", "", {}, "sha512-ts6Wi+2j3jQjqi70w5AlN8DFnkSwC+MqmxEzdEALB2qXZYV3X/b1CTfgPLGJNMeAWxdPfU8FO1ms3NUfaHCPYg=="], @@ -2370,9 +2382,9 @@ "chrome-launcher/is-wsl": ["is-wsl@2.2.0", "", { "dependencies": { "is-docker": "^2.0.0" } }, "sha512-fKzAra0rGJUUBwGBgNkHZuToZcn+TtXHpeCgmkMJMMYx1sQDYaCSyjJBSCa2nH1DGm7s3n1oBnohoVTBaN7Lww=="], - "clean-css/source-map": ["source-map@0.6.1", "", {}, "sha512-UjgapumWlbMhkBgzT7Ykc5YXUT46F0iKu8SGXq0bcwP5dz/h0Plj6enJqjz1Zbq2l5WaqYnrVbwWOWMyF3F47g=="], + "chromium-bidi/zod": ["zod@3.25.76", "", {}, "sha512-gzUt/qt81nXsFGKIFcC3YnfEAx5NkunCfnDlvuBSSFS02bcXu4Lmea0AFIUwbLWxWPx3d9p8S5QoaujKcNQxcQ=="], - "cliui/string-width": ["string-width@4.2.3", "", { "dependencies": { "emoji-regex": "^8.0.0", "is-fullwidth-code-point": "^3.0.0", "strip-ansi": "^6.0.1" } }, "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g=="], + "clean-css/source-map": ["source-map@0.6.1", "", {}, "sha512-UjgapumWlbMhkBgzT7Ykc5YXUT46F0iKu8SGXq0bcwP5dz/h0Plj6enJqjz1Zbq2l5WaqYnrVbwWOWMyF3F47g=="], "cliui/strip-ansi": ["strip-ansi@6.0.1", "", { "dependencies": { "ansi-regex": "^5.0.1" } }, "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A=="], @@ -2404,6 +2416,8 @@ "lighthouse/ws": ["ws@7.5.10", "", { "peerDependencies": { "bufferutil": "^4.0.1", "utf-8-validate": "^5.0.2" }, "optionalPeers": ["bufferutil", "utf-8-validate"] }, "sha512-+dbF1tHwZpXcbOJdVOkzLDxZP1ailvSxM6ZweXTegylPny803bFhA+vqBYw4s31NSAk4S2Qz+AKXK9a4wkdjcQ=="], + "lighthouse/yargs-parser": ["yargs-parser@21.1.1", "", {}, "sha512-tVpsJW7DdjecAiFpbIB1e3qxIQsE6NoPc5/eTdrbbIC4h0LVsWhnoa3g+m2HclBIujHzsxZ4VJVA+GUuc2/LBw=="], + "listhen/pathe": ["pathe@1.1.2", "", {}, "sha512-whLdWMYL2TwI08hn8/ZqAbrVemu0LNaNNJZX73O6qaIdCTfXutsLhMkjdENX0qhsQ9uIimo4/aQOmXkoon2nDQ=="], "local-pkg/quansync": ["quansync@0.2.11", "", {}, "sha512-AifT7QEbW9Nri4tAwR5M/uzpBuqfZf+zwaEM/QkzEjj7NBuFD2rBuy0K3dE+8wltbezDV7JMA0WfnCPYRSYbXA=="], @@ -2434,10 +2448,14 @@ "proxy-agent/lru-cache": ["lru-cache@7.18.3", "", {}, "sha512-jumlc0BIUrS3qJGgIkWZsyfAM7NCWiBcCDhnd+3NNM5KbBmLTgHVfWBcg6W+rLUsIpzpERPsvwUP7CckAQSOoA=="], + "sitemapper/p-limit": ["p-limit@6.2.0", "", { "dependencies": { "yocto-queue": "^1.1.1" } }, "sha512-kuUqqHNUqoIWp/c467RI4X6mmyuojY5jGutNU0wVTmEOOfcuwLqyMVoAi9MKi2Ak+5i9+nhmrK4ufZE8069kHA=="], + "source-map-support/source-map": ["source-map@0.6.1", "", {}, "sha512-UjgapumWlbMhkBgzT7Ykc5YXUT46F0iKu8SGXq0bcwP5dz/h0Plj6enJqjz1Zbq2l5WaqYnrVbwWOWMyF3F47g=="], "speedline-core/@types/node": ["@types/node@25.0.3", "", { "dependencies": { "undici-types": "~7.16.0" } }, "sha512-W609buLVRVmeW693xKfzHeIV6nJGGz98uCPfeXI1ELMLXVeKYZ9m15fAMSaUPBHYLGFsVRcMmSCksQOrZV9BYA=="], + "string-width/strip-ansi": ["strip-ansi@6.0.1", "", { "dependencies": { "ansi-regex": "^5.0.1" } }, "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A=="], + "strip-literal/js-tokens": ["js-tokens@9.0.1", "", {}, "sha512-mxa9E9ITFOt0ban3j6L5MpjwegGz6lBQmM1IJkWeBZGcMxto50+eWdjC/52xDbS2vy0k7vIMK0Fe2wfL9OQSpQ=="], "svgo/commander": ["commander@11.1.0", "", {}, "sha512-yPVavfyCcRhmorC7rWlkHn15b4wDVgVmBA7kV4QVBsF7kv/9TKJAbAXVTxvTnwP8HHKjRCJDClKbciiYS7p0DQ=="], @@ -2462,17 +2480,19 @@ "vaul-vue/@vueuse/core": ["@vueuse/core@10.11.1", "", { "dependencies": { "@types/web-bluetooth": "^0.0.20", "@vueuse/metadata": "10.11.1", "@vueuse/shared": "10.11.1", "vue-demi": ">=0.14.8" } }, "sha512-guoy26JQktXPcz+0n3GukWIy/JDNKti9v6VEMu6kV2sYBsWuGiTU8OWdg+ADfUbHg3/3DlqySDe7JmdHrktiww=="], - "vite/esbuild": ["esbuild@0.25.12", "", { "optionalDependencies": { "@esbuild/aix-ppc64": "0.25.12", "@esbuild/android-arm": "0.25.12", "@esbuild/android-arm64": "0.25.12", "@esbuild/android-x64": "0.25.12", "@esbuild/darwin-arm64": "0.25.12", "@esbuild/darwin-x64": "0.25.12", "@esbuild/freebsd-arm64": "0.25.12", "@esbuild/freebsd-x64": "0.25.12", "@esbuild/linux-arm": "0.25.12", "@esbuild/linux-arm64": "0.25.12", "@esbuild/linux-ia32": "0.25.12", "@esbuild/linux-loong64": "0.25.12", "@esbuild/linux-mips64el": "0.25.12", "@esbuild/linux-ppc64": "0.25.12", "@esbuild/linux-riscv64": "0.25.12", "@esbuild/linux-s390x": "0.25.12", "@esbuild/linux-x64": "0.25.12", "@esbuild/netbsd-arm64": "0.25.12", "@esbuild/netbsd-x64": "0.25.12", "@esbuild/openbsd-arm64": "0.25.12", "@esbuild/openbsd-x64": "0.25.12", "@esbuild/openharmony-arm64": "0.25.12", "@esbuild/sunos-x64": "0.25.12", "@esbuild/win32-arm64": "0.25.12", "@esbuild/win32-ia32": "0.25.12", "@esbuild/win32-x64": "0.25.12" }, "bin": { "esbuild": "bin/esbuild" } }, "sha512-bbPBYYrtZbkt6Os6FiTLCTFxvq4tt3JKall1vRwshA3fdVztsLAatFaZobhkBC8/BrPetoa0oksYoKXoG4ryJg=="], - "vscode-json-languageservice/jsonc-parser": ["jsonc-parser@3.3.1", "", {}, "sha512-HUgH65KyejrUFPvHFPbqOY0rsFip3Bo5wb4ngvdi1EpCYWUQDC5V+Y7mZws+DLkr4M//zQJoanu1SP+87Dv1oQ=="], + "widest-line/string-width": ["string-width@7.2.0", "", { "dependencies": { "emoji-regex": "^10.3.0", "get-east-asian-width": "^1.0.0", "strip-ansi": "^7.1.0" } }, "sha512-tsaTIkKW9b4N+AEj+SVA+WhJzV7/zMhcSu78mLKWSk7cXMOSHsBKFWUs0fWwq8QyK3MgJBQRX6Gbi4kYbdvGkQ=="], + "wrap-ansi/string-width": ["string-width@8.2.0", "", { "dependencies": { "get-east-asian-width": "^1.5.0", "strip-ansi": "^7.1.2" } }, "sha512-6hJPQ8N0V0P3SNmP6h2J99RLuzrWz2gvT7VnK5tKvrNqJoyS9W4/Fb8mo31UiPvy00z7DQXkP2hnKBVav76thw=="], "yaml-language-server/request-light": ["request-light@0.5.8", "", {}, "sha512-3Zjgh+8b5fhRJBQZoy+zbVKpAQGLyka0MPgW3zruTF4dFFJ8Fqcfu9YsAvi/rvdcaTeWG3MkbZv4WKxAn/84Lg=="], "yaml-language-server/yaml": ["yaml@2.7.1", "", { "bin": { "yaml": "bin.mjs" } }, "sha512-10ULxpnOCQXxJvBgxsn9ptjq6uviG/htZKk9veJGhlqn3w/DxQ631zFF+nlQXLwmImeS5amR2dl2U8sg6U9jsQ=="], - "yargs/string-width": ["string-width@4.2.3", "", { "dependencies": { "emoji-regex": "^8.0.0", "is-fullwidth-code-point": "^3.0.0", "strip-ansi": "^6.0.1" } }, "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g=="], + "yargs/yargs-parser": ["yargs-parser@21.1.1", "", {}, "sha512-tVpsJW7DdjecAiFpbIB1e3qxIQsE6NoPc5/eTdrbbIC4h0LVsWhnoa3g+m2HclBIujHzsxZ4VJVA+GUuc2/LBw=="], + + "zod-to-ts/zod": ["zod@3.25.76", "", {}, "sha512-gzUt/qt81nXsFGKIFcC3YnfEAx5NkunCfnDlvuBSSFS02bcXu4Lmea0AFIUwbLWxWPx3d9p8S5QoaujKcNQxcQ=="], "@astrojs/check/chokidar/readdirp": ["readdirp@3.6.0", "", { "dependencies": { "picomatch": "^2.2.1" } }, "sha512-hOS089on8RduqdbhvQ5Z37A0ESjsqz6qnRcffsMU3495FuTdqSm+7bhJ29JvIOsBDEEnan5DPu9t3To9VRlMzA=="], @@ -2496,6 +2516,8 @@ "@lhci/utils/lighthouse/ws": ["ws@7.5.10", "", { "peerDependencies": { "bufferutil": "^4.0.1", "utf-8-validate": "^5.0.2" }, "optionalPeers": ["bufferutil", "utf-8-validate"] }, "sha512-+dbF1tHwZpXcbOJdVOkzLDxZP1ailvSxM6ZweXTegylPny803bFhA+vqBYw4s31NSAk4S2Qz+AKXK9a4wkdjcQ=="], + "@lhci/utils/lighthouse/yargs-parser": ["yargs-parser@21.1.1", "", {}, "sha512-tVpsJW7DdjecAiFpbIB1e3qxIQsE6NoPc5/eTdrbbIC4h0LVsWhnoa3g+m2HclBIujHzsxZ4VJVA+GUuc2/LBw=="], + "@nuxtjs/color-mode/@nuxt/kit/pathe": ["pathe@2.0.3", "", {}, "sha512-WUjGcAqP1gQacoQe+OBJsFA7Ld4DyXuUIjZ5cc75cLHvJ7dtNsTugphxIADwspS+AraAUePCKrSVtPLFj/F88w=="], "@nuxtjs/color-mode/@nuxt/kit/pkg-types": ["pkg-types@2.3.0", "", { "dependencies": { "confbox": "^0.2.2", "exsolve": "^1.0.7", "pathe": "^2.0.3" } }, "sha512-SIqCzDRg0s9npO5XQ3tNZioRY1uK06lA41ynBC1YmFTmnY6FjUjVt6s4LoADmwoig1qqD0oK8h1p/8mlMx8Oig=="], @@ -2506,10 +2528,30 @@ "@nuxtjs/color-mode/pkg-types/pathe": ["pathe@2.0.3", "", {}, "sha512-WUjGcAqP1gQacoQe+OBJsFA7Ld4DyXuUIjZ5cc75cLHvJ7dtNsTugphxIADwspS+AraAUePCKrSVtPLFj/F88w=="], + "@playform/compress/astro/@astrojs/internal-helpers": ["@astrojs/internal-helpers@0.7.5", "", {}, "sha512-vreGnYSSKhAjFJCWAwe/CNhONvoc5lokxtRoZims+0wa3KbHBdPHSSthJsKxPd8d/aic6lWKpRTYGY/hsgK6EA=="], + + "@playform/compress/astro/@astrojs/markdown-remark": ["@astrojs/markdown-remark@6.3.10", "", { "dependencies": { "@astrojs/internal-helpers": "0.7.5", "@astrojs/prism": "3.3.0", "github-slugger": "^2.0.0", "hast-util-from-html": "^2.0.3", "hast-util-to-text": "^4.0.2", "import-meta-resolve": "^4.2.0", "js-yaml": "^4.1.1", "mdast-util-definitions": "^6.0.0", "rehype-raw": "^7.0.0", "rehype-stringify": "^10.0.1", "remark-gfm": "^4.0.1", "remark-parse": "^11.0.0", "remark-rehype": "^11.1.2", "remark-smartypants": "^3.0.2", "shiki": "^3.19.0", "smol-toml": "^1.5.2", "unified": "^11.0.5", "unist-util-remove-position": "^5.0.0", "unist-util-visit": "^5.0.0", "unist-util-visit-parents": "^6.0.2", "vfile": "^6.0.3" } }, "sha512-kk4HeYR6AcnzC4QV8iSlOfh+N8TZ3MEStxPyenyCtemqn8IpEATBFMTJcfrNW32dgpt6MY3oCkMM/Tv3/I4G3A=="], + + "@playform/compress/astro/common-ancestor-path": ["common-ancestor-path@1.0.1", "", {}, "sha512-L3sHRo1pXXEqX8VU28kfgUY+YGsk09hPqZiZmLacNib6XNTCM8ubYeT7ryXQw8asB1sKgcU5lkB7ONug08aB8w=="], + "@playform/compress/astro/diff": ["diff@5.2.2", "", {}, "sha512-vtcDfH3TOjP8UekytvnHH1o1P4FcUdt4eQ1Y+Abap1tk/OB2MWQvcwS2ClCd1zuIhc3JKOx6p3kod8Vfys3E+A=="], + "@playform/compress/astro/es-module-lexer": ["es-module-lexer@1.7.0", "", {}, "sha512-jEQoCwk8hyb2AZziIOLhDqpm5+2ww5uIE6lkO/6jcOCusfk6LhMHpXXfBLXTZ7Ydyt0j4VoUQv6uGNYbdW+kBA=="], + "@playform/compress/astro/esbuild": ["esbuild@0.25.12", "", { "optionalDependencies": { "@esbuild/aix-ppc64": "0.25.12", "@esbuild/android-arm": "0.25.12", "@esbuild/android-arm64": "0.25.12", "@esbuild/android-x64": "0.25.12", "@esbuild/darwin-arm64": "0.25.12", "@esbuild/darwin-x64": "0.25.12", "@esbuild/freebsd-arm64": "0.25.12", "@esbuild/freebsd-x64": "0.25.12", "@esbuild/linux-arm": "0.25.12", "@esbuild/linux-arm64": "0.25.12", "@esbuild/linux-ia32": "0.25.12", "@esbuild/linux-loong64": "0.25.12", "@esbuild/linux-mips64el": "0.25.12", "@esbuild/linux-ppc64": "0.25.12", "@esbuild/linux-riscv64": "0.25.12", "@esbuild/linux-s390x": "0.25.12", "@esbuild/linux-x64": "0.25.12", "@esbuild/netbsd-arm64": "0.25.12", "@esbuild/netbsd-x64": "0.25.12", "@esbuild/openbsd-arm64": "0.25.12", "@esbuild/openbsd-x64": "0.25.12", "@esbuild/openharmony-arm64": "0.25.12", "@esbuild/sunos-x64": "0.25.12", "@esbuild/win32-arm64": "0.25.12", "@esbuild/win32-ia32": "0.25.12", "@esbuild/win32-x64": "0.25.12" }, "bin": { "esbuild": "bin/esbuild" } }, "sha512-bbPBYYrtZbkt6Os6FiTLCTFxvq4tt3JKall1vRwshA3fdVztsLAatFaZobhkBC8/BrPetoa0oksYoKXoG4ryJg=="], + "@playform/compress/astro/p-limit": ["p-limit@6.2.0", "", { "dependencies": { "yocto-queue": "^1.1.1" } }, "sha512-kuUqqHNUqoIWp/c467RI4X6mmyuojY5jGutNU0wVTmEOOfcuwLqyMVoAi9MKi2Ak+5i9+nhmrK4ufZE8069kHA=="], + + "@playform/compress/astro/p-queue": ["p-queue@8.1.1", "", { "dependencies": { "eventemitter3": "^5.0.1", "p-timeout": "^6.1.2" } }, "sha512-aNZ+VfjobsWryoiPnEApGGmf5WmNsCo9xu8dfaYamG5qaLP7ClhLN6NgsFe6SwJ2UbLEBK5dv9x8Mn5+RVhMWQ=="], + + "@playform/compress/astro/shiki": ["shiki@3.23.0", "", { "dependencies": { "@shikijs/core": "3.23.0", "@shikijs/engine-javascript": "3.23.0", "@shikijs/engine-oniguruma": "3.23.0", "@shikijs/langs": "3.23.0", "@shikijs/themes": "3.23.0", "@shikijs/types": "3.23.0", "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4" } }, "sha512-55Dj73uq9ZXL5zyeRPzHQsK7Nbyt6Y10k5s7OjuFZGMhpp4r/rsLBH0o/0fstIzX1Lep9VxefWljK/SKCzygIA=="], + + "@playform/compress/astro/vite": ["vite@6.4.1", "", { "dependencies": { "esbuild": "^0.25.0", "fdir": "^6.4.4", "picomatch": "^4.0.2", "postcss": "^8.5.3", "rollup": "^4.34.9", "tinyglobby": "^0.2.13" }, "optionalDependencies": { "fsevents": "~2.3.3" }, "peerDependencies": { "@types/node": "^18.0.0 || ^20.0.0 || >=22.0.0", "jiti": ">=1.21.0", "less": "*", "lightningcss": "^1.21.0", "sass": "*", "sass-embedded": "*", "stylus": "*", "sugarss": "*", "terser": "^5.16.0", "tsx": "^4.8.1", "yaml": "^2.4.2" }, "optionalPeers": ["@types/node", "jiti", "less", "lightningcss", "sass", "sass-embedded", "stylus", "sugarss", "terser", "tsx", "yaml"], "bin": { "vite": "bin/vite.js" } }, "sha512-+Oxm7q9hDoLMyJOYfUYBuHQo+dkAloi33apOPP56pzj+vsdJDzr+j1NISE5pyaAuKL4A3UD34qd0lx5+kfKp2g=="], + + "@playform/compress/astro/yargs-parser": ["yargs-parser@21.1.1", "", {}, "sha512-tVpsJW7DdjecAiFpbIB1e3qxIQsE6NoPc5/eTdrbbIC4h0LVsWhnoa3g+m2HclBIujHzsxZ4VJVA+GUuc2/LBw=="], + + "@playform/compress/astro/zod": ["zod@3.25.76", "", {}, "sha512-gzUt/qt81nXsFGKIFcC3YnfEAx5NkunCfnDlvuBSSFS02bcXu4Lmea0AFIUwbLWxWPx3d9p8S5QoaujKcNQxcQ=="], + "@tailwindcss/node/lightningcss/lightningcss-android-arm64": ["lightningcss-android-arm64@1.31.1", "", { "os": "android", "cpu": "arm64" }, "sha512-HXJF3x8w9nQ4jbXRiNppBCqeZPIAfUo8zE/kOEGbW5NZvGc/K7nMxbhIr+YlFlHW5mpbg/YFPdbnCh1wAXCKFg=="], "@tailwindcss/node/lightningcss/lightningcss-darwin-arm64": ["lightningcss-darwin-arm64@1.31.1", "", { "os": "darwin", "cpu": "arm64" }, "sha512-02uTEqf3vIfNMq3h/z2cJfcOXnQ0GRwQrkmPafhueLb2h7mqEidiCzkE4gBMEH65abHRiQvhdcQ+aP0D0g67sg=="], @@ -2532,14 +2574,10 @@ "@tailwindcss/node/lightningcss/lightningcss-win32-x64-msvc": ["lightningcss-win32-x64-msvc@1.31.1", "", { "os": "win32", "cpu": "x64" }, "sha512-I9aiFrbd7oYHwlnQDqr1Roz+fTz61oDDJX7n9tYF9FJymH1cIN1DtKw3iYt6b8WZgEjoNwVSncwF4wx/ZedMhw=="], - "ansi-align/string-width/emoji-regex": ["emoji-regex@8.0.0", "", {}, "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A=="], - - "ansi-align/string-width/strip-ansi": ["strip-ansi@6.0.1", "", { "dependencies": { "ansi-regex": "^5.0.1" } }, "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A=="], + "boxen/string-width/emoji-regex": ["emoji-regex@10.6.0", "", {}, "sha512-toUI84YS5YmxW219erniWD0CIVOo46xGKColeNQRgOzDorgBi1v4D71/OFzgD9GO2UGKIv1C3Sp8DAn0+j5w7A=="], "chrome-launcher/is-wsl/is-docker": ["is-docker@2.2.1", "", { "bin": { "is-docker": "cli.js" } }, "sha512-F+i2BKsFrH66iaUFc0woD8sLy8getkwTwtOBjvs56Cx4CgJDeKQeqfz8wAYiSb8JOprWhHH5p77PbmYCvvUuXQ=="], - "cliui/string-width/emoji-regex": ["emoji-regex@8.0.0", "", {}, "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A=="], - "cliui/strip-ansi/ansi-regex": ["ansi-regex@5.0.1", "", {}, "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ=="], "cliui/wrap-ansi/ansi-styles": ["ansi-styles@4.3.0", "", { "dependencies": { "color-convert": "^2.0.1" } }, "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg=="], @@ -2574,6 +2612,8 @@ "mlly/pkg-types/confbox": ["confbox@0.1.8", "", {}, "sha512-RMtmw0iFkeR4YV+fUOSucriAQNb9g8zFR52MWCtl+cCZOFRNL6zeB395vPzFhEjjn4fMxXudmELnl/KF/WrK6w=="], + "string-width/strip-ansi/ansi-regex": ["ansi-regex@5.0.1", "", {}, "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ=="], + "svgo/css-tree/mdn-data": ["mdn-data@2.27.1", "", {}, "sha512-9Yubnt3e8A0OKwxYSXyhLymGW4sCufcLG6VdiDdUGVkPhpqLxlvP5vl1983gQjJl3tqbrM731mjaZaP68AgosQ=="], "unifont/css-tree/mdn-data": ["mdn-data@2.27.1", "", {}, "sha512-9Yubnt3e8A0OKwxYSXyhLymGW4sCufcLG6VdiDdUGVkPhpqLxlvP5vl1983gQjJl3tqbrM731mjaZaP68AgosQ=="], @@ -2584,61 +2624,7 @@ "vaul-vue/@vueuse/core/@vueuse/shared": ["@vueuse/shared@10.11.1", "", { "dependencies": { "vue-demi": ">=0.14.8" } }, "sha512-LHpC8711VFZlDaYUXEBbFBCQ7GS3dVU9mjOhhMhXP6txTV4EhYQg/KGnQuvt/sPAtoUKq7VVUnL6mVtFoL42sA=="], - "vite/esbuild/@esbuild/aix-ppc64": ["@esbuild/aix-ppc64@0.25.12", "", { "os": "aix", "cpu": "ppc64" }, "sha512-Hhmwd6CInZ3dwpuGTF8fJG6yoWmsToE+vYgD4nytZVxcu1ulHpUQRAB1UJ8+N1Am3Mz4+xOByoQoSZf4D+CpkA=="], - - "vite/esbuild/@esbuild/android-arm": ["@esbuild/android-arm@0.25.12", "", { "os": "android", "cpu": "arm" }, "sha512-VJ+sKvNA/GE7Ccacc9Cha7bpS8nyzVv0jdVgwNDaR4gDMC/2TTRc33Ip8qrNYUcpkOHUT5OZ0bUcNNVZQ9RLlg=="], - - "vite/esbuild/@esbuild/android-arm64": ["@esbuild/android-arm64@0.25.12", "", { "os": "android", "cpu": "arm64" }, "sha512-6AAmLG7zwD1Z159jCKPvAxZd4y/VTO0VkprYy+3N2FtJ8+BQWFXU+OxARIwA46c5tdD9SsKGZ/1ocqBS/gAKHg=="], - - "vite/esbuild/@esbuild/android-x64": ["@esbuild/android-x64@0.25.12", "", { "os": "android", "cpu": "x64" }, "sha512-5jbb+2hhDHx5phYR2By8GTWEzn6I9UqR11Kwf22iKbNpYrsmRB18aX/9ivc5cabcUiAT/wM+YIZ6SG9QO6a8kg=="], - - "vite/esbuild/@esbuild/darwin-arm64": ["@esbuild/darwin-arm64@0.25.12", "", { "os": "darwin", "cpu": "arm64" }, "sha512-N3zl+lxHCifgIlcMUP5016ESkeQjLj/959RxxNYIthIg+CQHInujFuXeWbWMgnTo4cp5XVHqFPmpyu9J65C1Yg=="], - - "vite/esbuild/@esbuild/darwin-x64": ["@esbuild/darwin-x64@0.25.12", "", { "os": "darwin", "cpu": "x64" }, "sha512-HQ9ka4Kx21qHXwtlTUVbKJOAnmG1ipXhdWTmNXiPzPfWKpXqASVcWdnf2bnL73wgjNrFXAa3yYvBSd9pzfEIpA=="], - - "vite/esbuild/@esbuild/freebsd-arm64": ["@esbuild/freebsd-arm64@0.25.12", "", { "os": "freebsd", "cpu": "arm64" }, "sha512-gA0Bx759+7Jve03K1S0vkOu5Lg/85dou3EseOGUes8flVOGxbhDDh/iZaoek11Y8mtyKPGF3vP8XhnkDEAmzeg=="], - - "vite/esbuild/@esbuild/freebsd-x64": ["@esbuild/freebsd-x64@0.25.12", "", { "os": "freebsd", "cpu": "x64" }, "sha512-TGbO26Yw2xsHzxtbVFGEXBFH0FRAP7gtcPE7P5yP7wGy7cXK2oO7RyOhL5NLiqTlBh47XhmIUXuGciXEqYFfBQ=="], - - "vite/esbuild/@esbuild/linux-arm": ["@esbuild/linux-arm@0.25.12", "", { "os": "linux", "cpu": "arm" }, "sha512-lPDGyC1JPDou8kGcywY0YILzWlhhnRjdof3UlcoqYmS9El818LLfJJc3PXXgZHrHCAKs/Z2SeZtDJr5MrkxtOw=="], - - "vite/esbuild/@esbuild/linux-arm64": ["@esbuild/linux-arm64@0.25.12", "", { "os": "linux", "cpu": "arm64" }, "sha512-8bwX7a8FghIgrupcxb4aUmYDLp8pX06rGh5HqDT7bB+8Rdells6mHvrFHHW2JAOPZUbnjUpKTLg6ECyzvas2AQ=="], - - "vite/esbuild/@esbuild/linux-ia32": ["@esbuild/linux-ia32@0.25.12", "", { "os": "linux", "cpu": "ia32" }, "sha512-0y9KrdVnbMM2/vG8KfU0byhUN+EFCny9+8g202gYqSSVMonbsCfLjUO+rCci7pM0WBEtz+oK/PIwHkzxkyharA=="], - - "vite/esbuild/@esbuild/linux-loong64": ["@esbuild/linux-loong64@0.25.12", "", { "os": "linux", "cpu": "none" }, "sha512-h///Lr5a9rib/v1GGqXVGzjL4TMvVTv+s1DPoxQdz7l/AYv6LDSxdIwzxkrPW438oUXiDtwM10o9PmwS/6Z0Ng=="], - - "vite/esbuild/@esbuild/linux-mips64el": ["@esbuild/linux-mips64el@0.25.12", "", { "os": "linux", "cpu": "none" }, "sha512-iyRrM1Pzy9GFMDLsXn1iHUm18nhKnNMWscjmp4+hpafcZjrr2WbT//d20xaGljXDBYHqRcl8HnxbX6uaA/eGVw=="], - - "vite/esbuild/@esbuild/linux-ppc64": ["@esbuild/linux-ppc64@0.25.12", "", { "os": "linux", "cpu": "ppc64" }, "sha512-9meM/lRXxMi5PSUqEXRCtVjEZBGwB7P/D4yT8UG/mwIdze2aV4Vo6U5gD3+RsoHXKkHCfSxZKzmDssVlRj1QQA=="], - - "vite/esbuild/@esbuild/linux-riscv64": ["@esbuild/linux-riscv64@0.25.12", "", { "os": "linux", "cpu": "none" }, "sha512-Zr7KR4hgKUpWAwb1f3o5ygT04MzqVrGEGXGLnj15YQDJErYu/BGg+wmFlIDOdJp0PmB0lLvxFIOXZgFRrdjR0w=="], - - "vite/esbuild/@esbuild/linux-s390x": ["@esbuild/linux-s390x@0.25.12", "", { "os": "linux", "cpu": "s390x" }, "sha512-MsKncOcgTNvdtiISc/jZs/Zf8d0cl/t3gYWX8J9ubBnVOwlk65UIEEvgBORTiljloIWnBzLs4qhzPkJcitIzIg=="], - - "vite/esbuild/@esbuild/linux-x64": ["@esbuild/linux-x64@0.25.12", "", { "os": "linux", "cpu": "x64" }, "sha512-uqZMTLr/zR/ed4jIGnwSLkaHmPjOjJvnm6TVVitAa08SLS9Z0VM8wIRx7gWbJB5/J54YuIMInDquWyYvQLZkgw=="], - - "vite/esbuild/@esbuild/netbsd-arm64": ["@esbuild/netbsd-arm64@0.25.12", "", { "os": "none", "cpu": "arm64" }, "sha512-xXwcTq4GhRM7J9A8Gv5boanHhRa/Q9KLVmcyXHCTaM4wKfIpWkdXiMog/KsnxzJ0A1+nD+zoecuzqPmCRyBGjg=="], - - "vite/esbuild/@esbuild/netbsd-x64": ["@esbuild/netbsd-x64@0.25.12", "", { "os": "none", "cpu": "x64" }, "sha512-Ld5pTlzPy3YwGec4OuHh1aCVCRvOXdH8DgRjfDy/oumVovmuSzWfnSJg+VtakB9Cm0gxNO9BzWkj6mtO1FMXkQ=="], - - "vite/esbuild/@esbuild/openbsd-arm64": ["@esbuild/openbsd-arm64@0.25.12", "", { "os": "openbsd", "cpu": "arm64" }, "sha512-fF96T6KsBo/pkQI950FARU9apGNTSlZGsv1jZBAlcLL1MLjLNIWPBkj5NlSz8aAzYKg+eNqknrUJ24QBybeR5A=="], - - "vite/esbuild/@esbuild/openbsd-x64": ["@esbuild/openbsd-x64@0.25.12", "", { "os": "openbsd", "cpu": "x64" }, "sha512-MZyXUkZHjQxUvzK7rN8DJ3SRmrVrke8ZyRusHlP+kuwqTcfWLyqMOE3sScPPyeIXN/mDJIfGXvcMqCgYKekoQw=="], - - "vite/esbuild/@esbuild/openharmony-arm64": ["@esbuild/openharmony-arm64@0.25.12", "", { "os": "none", "cpu": "arm64" }, "sha512-rm0YWsqUSRrjncSXGA7Zv78Nbnw4XL6/dzr20cyrQf7ZmRcsovpcRBdhD43Nuk3y7XIoW2OxMVvwuRvk9XdASg=="], - - "vite/esbuild/@esbuild/sunos-x64": ["@esbuild/sunos-x64@0.25.12", "", { "os": "sunos", "cpu": "x64" }, "sha512-3wGSCDyuTHQUzt0nV7bocDy72r2lI33QL3gkDNGkod22EsYl04sMf0qLb8luNKTOmgF/eDEDP5BFNwoBKH441w=="], - - "vite/esbuild/@esbuild/win32-arm64": ["@esbuild/win32-arm64@0.25.12", "", { "os": "win32", "cpu": "arm64" }, "sha512-rMmLrur64A7+DKlnSuwqUdRKyd3UE7oPJZmnljqEptesKM8wx9J8gx5u0+9Pq0fQQW8vqeKebwNXdfOyP+8Bsg=="], - - "vite/esbuild/@esbuild/win32-ia32": ["@esbuild/win32-ia32@0.25.12", "", { "os": "win32", "cpu": "ia32" }, "sha512-HkqnmmBoCbCwxUKKNPBixiWDGCpQGVsrQfJoVGYLPT41XWF8lHuE5N6WhVia2n4o5QK5M4tYr21827fNhi4byQ=="], - - "vite/esbuild/@esbuild/win32-x64": ["@esbuild/win32-x64@0.25.12", "", { "os": "win32", "cpu": "x64" }, "sha512-alJC0uCZpTFrSL0CCDjcgleBXPnCrEAhTBILpeAp7M/OFgoqtAetfBzX0xM00MUsVVPpVjlPuMbREqnZCXaTnA=="], - - "yargs/string-width/emoji-regex": ["emoji-regex@8.0.0", "", {}, "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A=="], - - "yargs/string-width/strip-ansi": ["strip-ansi@6.0.1", "", { "dependencies": { "ansi-regex": "^5.0.1" } }, "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A=="], + "widest-line/string-width/emoji-regex": ["emoji-regex@10.6.0", "", {}, "sha512-toUI84YS5YmxW219erniWD0CIVOo46xGKColeNQRgOzDorgBi1v4D71/OFzgD9GO2UGKIv1C3Sp8DAn0+j5w7A=="], "@astrojs/check/chokidar/readdirp/picomatch": ["picomatch@2.3.1", "", {}, "sha512-JU3teHTNjmE2VCGFzuY8EXzCDVwEqB2a8fsIvwaStHhAWJEeVd1o1QD80CU6+ZdEXXSLbSsuLwJjkCBWqRQUVA=="], @@ -2652,6 +2638,8 @@ "@lhci/utils/lighthouse/tldts-icann/tldts-core": ["tldts-core@6.1.86", "", {}, "sha512-Je6p7pkk+KMzMv2XXKmAE3McmolOQFdxkKw0R8EYNr7sELW46JqnNeTX8ybPiQgvg1ymCoF8LXs5fzFaZvJPTA=="], + "@playform/compress/astro/@astrojs/markdown-remark/@astrojs/prism": ["@astrojs/prism@3.3.0", "", { "dependencies": { "prismjs": "^1.30.0" } }, "sha512-q8VwfU/fDZNoDOf+r7jUnMC2//H2l0TuQ6FkGJL8vD8nw/q5KiL3DS1KKBI3QhI9UQhpJ5dc7AtqfbXWuOgLCQ=="], + "@playform/compress/astro/esbuild/@esbuild/aix-ppc64": ["@esbuild/aix-ppc64@0.25.12", "", { "os": "aix", "cpu": "ppc64" }, "sha512-Hhmwd6CInZ3dwpuGTF8fJG6yoWmsToE+vYgD4nytZVxcu1ulHpUQRAB1UJ8+N1Am3Mz4+xOByoQoSZf4D+CpkA=="], "@playform/compress/astro/esbuild/@esbuild/android-arm": ["@esbuild/android-arm@0.25.12", "", { "os": "android", "cpu": "arm" }, "sha512-VJ+sKvNA/GE7Ccacc9Cha7bpS8nyzVv0jdVgwNDaR4gDMC/2TTRc33Ip8qrNYUcpkOHUT5OZ0bUcNNVZQ9RLlg=="], @@ -2704,8 +2692,18 @@ "@playform/compress/astro/esbuild/@esbuild/win32-x64": ["@esbuild/win32-x64@0.25.12", "", { "os": "win32", "cpu": "x64" }, "sha512-alJC0uCZpTFrSL0CCDjcgleBXPnCrEAhTBILpeAp7M/OFgoqtAetfBzX0xM00MUsVVPpVjlPuMbREqnZCXaTnA=="], - "ansi-align/string-width/strip-ansi/ansi-regex": ["ansi-regex@5.0.1", "", {}, "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ=="], + "@playform/compress/astro/p-queue/p-timeout": ["p-timeout@6.1.4", "", {}, "sha512-MyIV3ZA/PmyBN/ud8vV9XzwTrNtR4jFrObymZYnZqMmW0zA8Z17vnT0rBgFE/TlohB+YCHqXMgZzb3Csp49vqg=="], + + "@playform/compress/astro/shiki/@shikijs/core": ["@shikijs/core@3.23.0", "", { "dependencies": { "@shikijs/types": "3.23.0", "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4", "hast-util-to-html": "^9.0.5" } }, "sha512-NSWQz0riNb67xthdm5br6lAkvpDJRTgB36fxlo37ZzM2yq0PQFFzbd8psqC2XMPgCzo1fW6cVi18+ArJ44wqgA=="], + + "@playform/compress/astro/shiki/@shikijs/engine-javascript": ["@shikijs/engine-javascript@3.23.0", "", { "dependencies": { "@shikijs/types": "3.23.0", "@shikijs/vscode-textmate": "^10.0.2", "oniguruma-to-es": "^4.3.4" } }, "sha512-aHt9eiGFobmWR5uqJUViySI1bHMqrAgamWE1TYSUoftkAeCCAiGawPMwM+VCadylQtF4V3VNOZ5LmfItH5f3yA=="], + + "@playform/compress/astro/shiki/@shikijs/engine-oniguruma": ["@shikijs/engine-oniguruma@3.23.0", "", { "dependencies": { "@shikijs/types": "3.23.0", "@shikijs/vscode-textmate": "^10.0.2" } }, "sha512-1nWINwKXxKKLqPibT5f4pAFLej9oZzQTsby8942OTlsJzOBZ0MWKiwzMsd+jhzu8YPCHAswGnnN1YtQfirL35g=="], + + "@playform/compress/astro/shiki/@shikijs/langs": ["@shikijs/langs@3.23.0", "", { "dependencies": { "@shikijs/types": "3.23.0" } }, "sha512-2Ep4W3Re5aB1/62RSYQInK9mM3HsLeB91cHqznAJMuylqjzNVAVCMnNWRHFtcNHXsoNRayP9z1qj4Sq3nMqYXg=="], + + "@playform/compress/astro/shiki/@shikijs/themes": ["@shikijs/themes@3.23.0", "", { "dependencies": { "@shikijs/types": "3.23.0" } }, "sha512-5qySYa1ZgAT18HR/ypENL9cUSGOeI2x+4IvYJu4JgVJdizn6kG4ia5Q1jDEOi7gTbN4RbuYtmHh0W3eccOrjMA=="], - "yargs/string-width/strip-ansi/ansi-regex": ["ansi-regex@5.0.1", "", {}, "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ=="], + "@playform/compress/astro/shiki/@shikijs/types": ["@shikijs/types@3.23.0", "", { "dependencies": { "@shikijs/vscode-textmate": "^10.0.2", "@types/hast": "^3.0.4" } }, "sha512-3JZ5HXOZfYjsYSk0yPwBrkupyYSLpAE26Qc0HLghhZNGTZg/SKxXIIgoxOpmmeQP0RRSDJTk1/vPfw9tbw+jSQ=="], } } diff --git a/website/package.json b/website/package.json index c7ff47c..332f695 100644 --- a/website/package.json +++ b/website/package.json @@ -13,9 +13,11 @@ "format:write": "prettier --write ." }, "dependencies": { - "@astrojs/mdx": "^4.3.13", - "@astrojs/react": "^4.4.0", - "@astrojs/sitemap": "^3.5.1", + "@astrojs/mdx": "5.0.2", + "@astrojs/react": "5.0.1", + "@astrojs/sitemap": "3.7.1", + "@fontsource/ibm-plex-mono": "^5.2.7", + "@fontsource/ibm-plex-sans": "^5.2.8", "@fontsource/inter": "^5.2.6", "@fontsource/prompt": "^5.2.6", "@lucide/astro": "^0.541.0", @@ -25,7 +27,7 @@ "@tailwindcss/typography": "^0.5.19", "@tailwindcss/vite": "^4.1.12", "@tanstack/react-table": "^8.21.3", - "astro": "^5.13.2", + "astro": "6.0.7", "astro-seo": "^0.8.4", "chart.js": "^4.5.1", "chartjs-plugin-datalabels": "^2.2.0", diff --git a/website/public/whitepaper/pdf/de-DE/whitepaper-v0.3.3.pdf b/website/public/whitepaper/pdf/de-DE/whitepaper-v0.3.3.pdf new file mode 100644 index 0000000..6fa7340 Binary files /dev/null and b/website/public/whitepaper/pdf/de-DE/whitepaper-v0.3.3.pdf differ diff --git a/website/public/whitepaper/pdf/en-US/whitepaper-v0.3.3.pdf b/website/public/whitepaper/pdf/en-US/whitepaper-v0.3.3.pdf new file mode 100644 index 0000000..7da8354 Binary files /dev/null and b/website/public/whitepaper/pdf/en-US/whitepaper-v0.3.3.pdf differ diff --git a/website/public/whitepaper/pdf/es-ES/whitepaper-v0.3.3.pdf b/website/public/whitepaper/pdf/es-ES/whitepaper-v0.3.3.pdf new file mode 100644 index 0000000..e68cef9 Binary files /dev/null and b/website/public/whitepaper/pdf/es-ES/whitepaper-v0.3.3.pdf differ diff --git a/website/public/whitepaper/pdf/hi-IN/whitepaper-v0.3.3.pdf b/website/public/whitepaper/pdf/hi-IN/whitepaper-v0.3.3.pdf new file mode 100644 index 0000000..c348a6d Binary files /dev/null and b/website/public/whitepaper/pdf/hi-IN/whitepaper-v0.3.3.pdf differ diff --git a/website/public/whitepaper/pdf/id-ID/whitepaper-v0.3.3.pdf b/website/public/whitepaper/pdf/id-ID/whitepaper-v0.3.3.pdf new file mode 100644 index 0000000..01f17e8 Binary files /dev/null and b/website/public/whitepaper/pdf/id-ID/whitepaper-v0.3.3.pdf differ diff --git a/website/public/whitepaper/pdf/ja-JP/whitepaper-v0.3.3.pdf b/website/public/whitepaper/pdf/ja-JP/whitepaper-v0.3.3.pdf new file mode 100644 index 0000000..eed2263 Binary files /dev/null and b/website/public/whitepaper/pdf/ja-JP/whitepaper-v0.3.3.pdf differ diff --git a/website/public/whitepaper/pdf/ko-KR/whitepaper-v0.3.3.pdf b/website/public/whitepaper/pdf/ko-KR/whitepaper-v0.3.3.pdf new file mode 100644 index 0000000..990b10d Binary files /dev/null and b/website/public/whitepaper/pdf/ko-KR/whitepaper-v0.3.3.pdf differ diff --git a/website/public/whitepaper/pdf/ru-RU/whitepaper-v0.3.3.pdf b/website/public/whitepaper/pdf/ru-RU/whitepaper-v0.3.3.pdf new file mode 100644 index 0000000..02516b6 Binary files /dev/null and b/website/public/whitepaper/pdf/ru-RU/whitepaper-v0.3.3.pdf differ diff --git a/website/public/whitepaper/pdf/zh-CN/whitepaper-v0.3.3.pdf b/website/public/whitepaper/pdf/zh-CN/whitepaper-v0.3.3.pdf new file mode 100644 index 0000000..44c126d Binary files /dev/null and b/website/public/whitepaper/pdf/zh-CN/whitepaper-v0.3.3.pdf differ diff --git a/website/public/whitepaper/v0.3.3/whitepaper-cover-decoration.webp b/website/public/whitepaper/v0.3.3/whitepaper-cover-decoration.webp new file mode 100644 index 0000000..ae53f42 Binary files /dev/null and b/website/public/whitepaper/v0.3.3/whitepaper-cover-decoration.webp differ diff --git a/website/scripts/generate-whitepaper-pdfs.js b/website/scripts/generate-whitepaper-pdfs.js index 72719e4..c47ce9a 100644 --- a/website/scripts/generate-whitepaper-pdfs.js +++ b/website/scripts/generate-whitepaper-pdfs.js @@ -117,33 +117,10 @@ async function generatePdf(puppeteer, locale, version) { timeout: 30000, }); - await page.waitForSelector("h1", { timeout: 30000 }); - - await page.evaluate(async () => { - await new Promise((resolve) => { - let totalHeight = 0; - let distance = 100; - let timer = setInterval(() => { - let scrollHeight = document.body.scrollHeight; - window.scrollBy(0, distance); - totalHeight += distance; - - if (totalHeight >= scrollHeight) { - clearInterval(timer); - resolve(); - } - }, 100); - }); - }); - - const LOGO_ICON = ``; - - const LOGO_TEXT = ``; - await page.pdf({ path: outputFile, format: "A4", - margin: { top: "60px", right: "50px", bottom: "80px", left: "50px" }, + margin: { top: "35px", right: "45px", bottom: "80px", left: "45px" }, printBackground: true, displayHeaderFooter: true, headerTemplate: ``, @@ -153,18 +130,17 @@ async function generatePdf(puppeteer, locale, version) { color: #666; width: 100%; padding: 8px 0 0; - margin: 0 76px; - border-top: 1px solid #d1d5db; + margin: 0 71px; + border-top: 1px solid #E8E8E8; display: flex; justify-content: space-between; align-items: center; "> -
- ${LOGO_ICON} - ${LOGO_TEXT} -
+ + QUANTUS.NETWORK + -
+
/
diff --git a/website/src/components/features/whitepaper/WhitepaperContent.astro b/website/src/components/features/whitepaper/WhitepaperContent.astro index 37fe1cc..6bb9270 100644 --- a/website/src/components/features/whitepaper/WhitepaperContent.astro +++ b/website/src/components/features/whitepaper/WhitepaperContent.astro @@ -1,48 +1,93 @@ --- +import { applyStyles } from "@/utils/apply-styles"; + export interface Props { class?: string; + styleVersion?: "v1" | "v2"; } -const { class: className = "" } = Astro.props; +const { class: className = "", styleVersion = "v1" } = Astro.props; + +const v1 = applyStyles([ + "prose prose-invert max-w-none [&>*:first-child]:mt-0", + "prose-headings:font-semibold prose-headings:tracking-tight", + "prose-h2:mt-12 prose-h2:mb-4 prose-h2:scroll-mt-24 prose-h2:border-white/10 prose-h2:pb-3 prose-h2:text-2xl lg:prose-h2:text-3xl", + "prose-h3:mt-8 prose-h3:mb-3 prose-h3:scroll-mt-24 prose-h3:text-xl lg:prose-h3:text-2xl", + "prose-h4:mt-6 prose-h4:mb-2 prose-h4:scroll-mt-24 prose-h4:text-lg", + "prose-p:leading-relaxed prose-p:text-white/70", + "prose-a:text-blue-400 prose-a:no-underline hover:prose-a:underline", + "prose-strong:text-white/90", + "prose-li:text-white/70 prose-li:marker:text-white/30", + "prose-ol:text-white/70 prose-ul:text-white/70", + "prose-code:rounded prose-code:bg-white/10 prose-code:px-1.5 prose-code:py-0.5 prose-code:text-sm prose-code:text-pink-300 prose-code:before:content-none prose-code:after:content-none", + "prose-pre:rounded-lg prose-pre:border prose-pre:border-white/10 prose-pre:bg-white/5", + "prose-table:overflow-hidden prose-table:rounded-lg prose-table:border prose-table:border-white/10", + "prose-th:border-b prose-th:border-white/10 prose-th:bg-white/5 prose-th:px-4 prose-th:py-3 prose-th:text-left prose-th:text-sm prose-th:font-semibold prose-th:text-white/80", + "prose-td:border-b prose-td:border-white/5 prose-td:px-4 prose-td:py-3 prose-td:text-sm prose-td:text-white/60", + "prose-hr:border-white/10", + "prose-blockquote:border-l-blue-500/40 prose-blockquote:text-white/60", + "prose-img:rounded-lg prose-img:border prose-img:border-white/10", + + "print:prose-headings:text-black", + "print:prose-p:text-[#333] print:prose-strong:text-black", + "print:prose-a:text-blue-700 print:prose-a:underline", + "print:prose-li:text-[#333] print:prose-li:marker:text-[#555]", + "print:prose-ol:text-[#333] print:prose-ul:text-[#333]", + "print:prose-code:text-[#c7254e] print:prose-code:bg-[#f9f2f4]", + "print:prose-pre:bg-[#f6f8fa] print:prose-pre:border-[#d0d7de]", + "print:prose-table:border-[#d0d7de]", + "print:prose-th:text-black print:prose-th:bg-[#f6f8fa] print:prose-th:border-[#d0d7de]", + "print:prose-td:text-[#333] print:prose-td:border-[#e1e4e8]", + "print:prose-hr:border-[#d0d7de]", + "print:prose-blockquote:border-l-blue-600 print:prose-blockquote:text-[#555]", + "print:prose-img:border-[#d0d7de]", + "print:prose-h2:border-[#d0d7de]", + className, +]); + +const v2 = applyStyles([ + "prose prose-invert max-w-none [&>*:first-child]:mt-0", + "prose-headings:font-semibold prose-headings:tracking-tight", + "prose-h2:mt-12 prose-h2:mb-4 prose-h2:scroll-mt-24 prose-h2:pb-3", + "prose-h3:mt-8 prose-h3:mb-3 prose-h3:scroll-mt-24 prose-h3:font-whitepaper-section-title", + "prose-h4:mt-6 prose-h4:mb-2 prose-h4:scroll-mt-24 prose-h4:font-whitepaper-sub-section-title prose-h4:text-whitepaper-primary", + "prose-p:font-whitepaper-section-paragraph prose-p:text-white/70", + "prose-a:text-blue-400 prose-a:no-underline hover:prose-a:underline", + "prose-strong:text-white/90", + "prose-ul:[&_li]:list-none prose-ul:p-0 prose-ul:[&_li]:before:content-['—'] prose-ul:[&_li]:before:mr-2 prose-ul:[&_li]:before:text-whitepaper-primary", + "prose-li:text-white/70 prose-li:font-whitepaper-section-paragraph prose-li:p-0", + "prose-ol:text-white/70 prose-ul:text-white/70", + "prose-code:font-whitepaper-code prose-code:py-0.5 prose-code:before:content-none prose-code:after:content-none", + "prose-pre:border-l-2 prose-pre:rounded-none prose-pre:border-whitepaper-primary prose-pre:bg-white/10!", + "prose-table:overflow-hidden prose-table:rounded-lg prose-table:border prose-table:border-white/10", + "prose-th:border-b prose-th:border-white/10 prose-th:bg-white/5 prose-th:px-4 prose-th:py-3 prose-th:text-left prose-th:text-sm prose-th:font-semibold prose-th:text-white/80", + "prose-td:border-b prose-td:border-white/5 prose-td:px-4 prose-td:py-3 prose-td:text-sm prose-td:text-white/60", + "prose-hr:border-white/10", + "prose-blockquote:border-l-whitepaper-primary prose-blockquote:font-whitepaper-blockquote prose-blockquote:border-l-2 prose-blockquote:text-white/60 prose-blockquote:[&>p::before]:content-none prose-blockquote:[&>p::after]:content-none prose-blockquote:[&>p]:not-italic", + "prose-img:rounded-lg prose-img:border prose-img:border-white/10", + + "print:prose-h2:text-whitepaper-body-light", + "print:prose-h3:text-whitepaper-body-light", + "print:prose-h4:text-whitepaper-primary", + "print:prose-p:text-whitepaper-body print:prose-strong:text-black", + "print:prose-a:text-blue-700 print:prose-a:underline", + "print:prose-li:text-[#333] print:prose-li:marker:text-[#555]", + "print:prose-ol:text-[#333] print:prose-ul:text-[#333]", + "print:prose-code:text-whitepaper-body-light", + "print:prose-pre:bg-whitepaper-pre-background!", + "print:prose-table:border-[#d0d7de]", + "print:prose-th:text-black print:prose-th:bg-[#f6f8fa] print:prose-th:border-[#d0d7de]", + "print:prose-td:text-[#333] print:prose-td:border-[#e1e4e8]", + "print:prose-hr:border-[#d0d7de]", + "print:prose-blockquote:text-whitepaper-body-light", + "print:prose-img:border-[#d0d7de]", + "print:prose-h2:border-[#d0d7de]", + className, +]); + +const appliedStyles = styleVersion === "v1" ? v1 : v2; --- -
*:first-child]:mt-0", - "prose-headings:font-semibold prose-headings:tracking-tight", - "prose-h2:mt-12 prose-h2:mb-4 prose-h2:scroll-mt-24 prose-h2:border-white/10 prose-h2:pb-3 prose-h2:text-2xl lg:prose-h2:text-3xl", - "prose-h3:mt-8 prose-h3:mb-3 prose-h3:scroll-mt-24 prose-h3:text-xl lg:prose-h3:text-2xl", - "prose-h4:mt-6 prose-h4:mb-2 prose-h4:scroll-mt-24 prose-h4:text-lg", - "prose-p:leading-relaxed prose-p:text-white/70", - "prose-a:text-blue-400 prose-a:no-underline hover:prose-a:underline", - "prose-strong:text-white/90", - "prose-li:text-white/70 prose-li:marker:text-white/30", - "prose-ol:text-white/70 prose-ul:text-white/70", - "prose-code:rounded prose-code:bg-white/10 prose-code:px-1.5 prose-code:py-0.5 prose-code:text-sm prose-code:text-pink-300 prose-code:before:content-none prose-code:after:content-none", - "prose-pre:rounded-lg prose-pre:border prose-pre:border-white/10 prose-pre:bg-white/5", - "prose-table:overflow-hidden prose-table:rounded-lg prose-table:border prose-table:border-white/10", - "prose-th:border-b prose-th:border-white/10 prose-th:bg-white/5 prose-th:px-4 prose-th:py-3 prose-th:text-left prose-th:text-sm prose-th:font-semibold prose-th:text-white/80", - "prose-td:border-b prose-td:border-white/5 prose-td:px-4 prose-td:py-3 prose-td:text-sm prose-td:text-white/60", - "prose-hr:border-white/10", - "prose-blockquote:border-l-blue-500/40 prose-blockquote:text-white/60", - "prose-img:rounded-lg prose-img:border prose-img:border-white/10", - - "print:prose-headings:text-black", - "print:prose-p:text-[#333] print:prose-strong:text-black", - "print:prose-a:text-blue-700 print:prose-a:underline", - "print:prose-li:text-[#333] print:prose-li:marker:text-[#555]", - "print:prose-ol:text-[#333] print:prose-ul:text-[#333]", - "print:prose-code:text-[#c7254e] print:prose-code:bg-[#f9f2f4]", - "print:prose-pre:bg-[#f6f8fa] print:prose-pre:border-[#d0d7de]", - "print:prose-table:border-[#d0d7de]", - "print:prose-th:text-black print:prose-th:bg-[#f6f8fa] print:prose-th:border-[#d0d7de]", - "print:prose-td:text-[#333] print:prose-td:border-[#e1e4e8]", - "print:prose-hr:border-[#d0d7de]", - "print:prose-blockquote:border-l-blue-600 print:prose-blockquote:text-[#555]", - "print:prose-img:border-[#d0d7de]", - "print:prose-h2:border-[#d0d7de]", - className, - ]} -> +
diff --git a/website/src/components/features/whitepaper/WhitepaperHeader.astro b/website/src/components/features/whitepaper/WhitepaperHeader.astro index 8ad2dfd..b34387a 100644 --- a/website/src/components/features/whitepaper/WhitepaperHeader.astro +++ b/website/src/components/features/whitepaper/WhitepaperHeader.astro @@ -15,6 +15,8 @@ export interface Props { pdfHref: string; locale: Locale; t: (key: string) => string; + /** When set with pdf cover, hide header in print so the cover replaces it. */ + class?: string; } const { @@ -28,13 +30,17 @@ const { pdfHref, locale, t, + class: className = "", } = Astro.props; const displayDate = updatedDate ?? publishedDate; ---
diff --git a/website/src/components/features/whitepaper/WhitepaperPrintCover.astro b/website/src/components/features/whitepaper/WhitepaperPrintCover.astro new file mode 100644 index 0000000..bb32da6 --- /dev/null +++ b/website/src/components/features/whitepaper/WhitepaperPrintCover.astro @@ -0,0 +1,100 @@ +--- +import type { Locale } from "@/utils/i18n"; +import { formatDate } from "@/utils/i18n"; + +export interface Props { + version: string; + + publishedDate: Date; + updatedDate?: Date; + locale: Locale; + t: (key: string) => string; +} + +const { version, publishedDate, updatedDate, locale, t } = Astro.props; + +const displayDate = updatedDate ?? publishedDate; +const formattedDate = formatDate(displayDate, locale, { + year: "numeric", + month: "long", + day: "numeric", +}); +--- + + + + diff --git a/website/src/components/features/whitepaper/mdx/CalloutV2.astro b/website/src/components/features/whitepaper/mdx/CalloutV2.astro new file mode 100644 index 0000000..c2541b3 --- /dev/null +++ b/website/src/components/features/whitepaper/mdx/CalloutV2.astro @@ -0,0 +1,22 @@ +--- +export interface Props { + title: string; +} + +const { title } = Astro.props; +--- + + diff --git a/website/src/components/features/whitepaper/mdx/ChapterHeading.astro b/website/src/components/features/whitepaper/mdx/ChapterHeading.astro new file mode 100644 index 0000000..be2682a --- /dev/null +++ b/website/src/components/features/whitepaper/mdx/ChapterHeading.astro @@ -0,0 +1,22 @@ +--- +export interface Props { + number: string; + title: string; +} + +const { number, title } = Astro.props; +--- + +

+ {number} + + {title} +

diff --git a/website/src/components/features/whitepaper/mdx/Divider.astro b/website/src/components/features/whitepaper/mdx/Divider.astro new file mode 100644 index 0000000..a87d700 --- /dev/null +++ b/website/src/components/features/whitepaper/mdx/Divider.astro @@ -0,0 +1 @@ +
diff --git a/website/src/components/features/whitepaper/mdx/Grid.astro b/website/src/components/features/whitepaper/mdx/Grid.astro index 4d01584..8a7f77d 100644 --- a/website/src/components/features/whitepaper/mdx/Grid.astro +++ b/website/src/components/features/whitepaper/mdx/Grid.astro @@ -1,12 +1,19 @@ --- export interface Props { + id?: string; cols?: number; gap?: string; align?: "start" | "center" | "end" | "stretch"; class?: string; } -const { cols, gap = "1.5rem", align = "start", class: className } = Astro.props; +const { + id, + cols, + gap = "1.5rem", + align = "start", + class: className, +} = Astro.props; // If cols is provided, we use a fixed grid. // If not, we use flexbox which allows children to define their own widths/ratios. @@ -14,6 +21,7 @@ const isFlex = !cols; ---
+ { + items.map((item, index) => ( + <> + + +
  • + + + {item.number} + + +
    + {item.title} +
    +
    +
  • + + {index === items.length - 1 && } + + )) + } + diff --git a/website/src/components/features/whitepaper/mdx/Reference.astro b/website/src/components/features/whitepaper/mdx/Reference.astro new file mode 100644 index 0000000..777f594 --- /dev/null +++ b/website/src/components/features/whitepaper/mdx/Reference.astro @@ -0,0 +1,23 @@ +--- +export interface Props { + id: string; + label: string; +} + +const { id, label } = Astro.props; +--- + +
    +
    + + {label} + +
    + +
    + +
    +
    diff --git a/website/src/components/features/whitepaper/mdx/ReferenceMarker.astro b/website/src/components/features/whitepaper/mdx/ReferenceMarker.astro new file mode 100644 index 0000000..f1f3d01 --- /dev/null +++ b/website/src/components/features/whitepaper/mdx/ReferenceMarker.astro @@ -0,0 +1,16 @@ +--- +export interface Props { + id: string; +} + +const { id } = Astro.props; +--- + + + + [{id}] + + diff --git a/website/src/components/features/whitepaper/mdx/ResponsiveTableV2.astro b/website/src/components/features/whitepaper/mdx/ResponsiveTableV2.astro new file mode 100644 index 0000000..b3ef1a8 --- /dev/null +++ b/website/src/components/features/whitepaper/mdx/ResponsiveTableV2.astro @@ -0,0 +1,88 @@ +--- +import { applyStyles } from "@/utils/apply-styles"; + +export interface Props { + headers: string[]; + rows: string[][]; + labelColumn?: number; + class?: string; +} + +const { headers, rows, labelColumn = 0, class: className } = Astro.props; + +const valueHeaders = headers.filter((_, i) => i !== labelColumn); +--- + +
    + {/* Desktop: standard table */} + + + {/* Mobile: card layout */} +
    + { + rows.map((row) => ( +
    +
    + + {row[labelColumn]} + +
    +
    + {valueHeaders.map((header, i) => { + const cellIndex = i >= labelColumn ? i + 1 : i; + return ( +
    + + {header} + + + {row[cellIndex]} + +
    + ); + })} +
    +
    + )) + } +
    +
    diff --git a/website/src/components/features/whitepaper/mdx/TimelineV2.astro b/website/src/components/features/whitepaper/mdx/TimelineV2.astro new file mode 100644 index 0000000..5895dbc --- /dev/null +++ b/website/src/components/features/whitepaper/mdx/TimelineV2.astro @@ -0,0 +1,31 @@ +--- +import Divider from "./Divider.astro"; + +export interface Props { + title: string; + date?: string; + subtitle?: string; +} + +const { title, date, subtitle } = Astro.props; +--- + + + +
    +
    + + {title} + + + + {date} + +
    + +
    + {subtitle} +
    +
    diff --git a/website/src/components/layout/Layout.astro b/website/src/components/layout/Layout.astro index 85e42dd..2506426 100644 --- a/website/src/components/layout/Layout.astro +++ b/website/src/components/layout/Layout.astro @@ -8,6 +8,15 @@ import "@fontsource/prompt/700.css"; import "@fontsource/prompt/900.css"; import "@fontsource/inter/900.css"; +// Whitepapers Fonts +import "@fontsource/ibm-plex-sans/400.css"; +import "@fontsource/ibm-plex-sans/400-italic.css"; +import "@fontsource/ibm-plex-sans/700.css"; +import "@fontsource/ibm-plex-mono/300.css"; +import "@fontsource/ibm-plex-mono/400.css"; +import "@fontsource/ibm-plex-mono/500.css"; +import "@fontsource/ibm-plex-mono/700.css"; + import Navbar from "./navbar/Navbar.astro"; import Footer from "./footer/Footer.astro"; diff --git a/website/src/content.config.ts b/website/src/content.config.ts index 174cc7a..718b9bf 100644 --- a/website/src/content.config.ts +++ b/website/src/content.config.ts @@ -15,6 +15,18 @@ const blog = defineCollection({ }), }); +const tocHeadingItem = z.object({ + slug: z.string(), + text: z.string(), + depth: z.number().optional(), +}); + +/** Merges with Astro `render().headings` so JSX/custom `

    ` (e.g. ChapterHeading) appear in the TOC. */ +const whitepaperToc = z.object({ + insertBefore: z.record(z.string(), z.array(tocHeadingItem)).optional(), + insertAfter: z.record(z.string(), z.array(tocHeadingItem)).optional(), +}); + const whitepaper = defineCollection({ loader: glob({ pattern: "**/*.{md,mdx}", @@ -27,6 +39,9 @@ const whitepaper = defineCollection({ updatedDate: z.coerce.date().optional(), authors: z.array(z.string()).default(["Quantus Labs"]), changelog: z.array(z.string()).default([]), + /** When true, PDF/print output includes a dedicated cover page and hides the in-page header. */ + pdfCover: z.boolean().optional(), + toc: whitepaperToc.optional(), }), }); diff --git a/website/src/contents/whitepapers/de-DE/v0.3.3.mdx b/website/src/contents/whitepapers/de-DE/v0.3.3.mdx new file mode 100644 index 0000000..ea0f1b3 --- /dev/null +++ b/website/src/contents/whitepapers/de-DE/v0.3.3.mdx @@ -0,0 +1,835 @@ +--- +title: "Quantus Network Whitepaper" +version: "0.3.3" +publishedDate: "2026-03-21" +updatedDate: "2026-03-21" +authors: ["Christopher Smith"] +changelog: + - "Umfassende Überarbeitung: Rechtlicher Hinweis, Inhaltsverzeichnis, nummerierte Kapitel (01–09), PDF-Deckblatt, TOC; „References & Further Reading“ ersetzt den Schlussabschnitt." + - "Neues Kapitel: Die Migrationskrise (Koordination, verlorene Coins, PQC-Migrationszeitplan)." + - "Einleitung und Kapitel zur Quantenbedrohung neu formuliert: CRQC-Rahmen, vier nummerierte Bedrohungskategorien, Zitate im Fließtext." + - "Architektur und technische Abschnitte erweitert oder präzisiert (Foundation/Substrate, LibP2P, Wormhole/Plonky2, Konsens/Goldilocks-Feld)." + - "Roadmap: Bell Mainnet Q2 2026; Fermi-Upgrade Q4 2026; Planck Beta um ZK-Integration ergänzt." +pdfCover: true +# Astro `render().headings` überspringt JSX-`

    ` und ChapterHeading; Anker-Slugs entsprechen den Markdown-`###`-IDs. +toc: + insertBefore: + die-quantenbedrohung: + - slug: legal-disclaimer + text: Rechtlicher Hinweis + - slug: contents + text: Inhalt + - slug: chapter-01 + text: Einführung + grundlagen-des-quantencomputings: + - slug: chapter-02 + text: Die Quantenbedrohung für die Blockchain + das-koordinationsproblem: + - slug: chapter-03 + text: Die Migrationskrise + grundlagen: + - slug: chapter-04 + text: Architektur von Quantus Network + umkehrbare-transaktionen: + - slug: chapter-05 + text: Vermögenserhalt + blockbelohnungen: + - slug: chapter-06 + text: Tokenomics und Governance + implementierungsprobleme: + - slug: chapter-07 + text: Roadmap + - slug: chapter-08 + text: Risiken + insertAfter: + sonstige-überlegungen: + - slug: chapter-09 + text: Referenzen und weiterführende Literatur +--- + +import CalloutV2 from "@/components/features/whitepaper/mdx/CalloutV2.astro"; +import Figure from "@/components/features/whitepaper/mdx/Figure.astro"; +import Grid from "@/components/features/whitepaper/mdx/Grid.astro"; +import Column from "@/components/features/whitepaper/mdx/Column.astro"; +import TimelineV2 from "@/components/features/whitepaper/mdx/TimelineV2.astro"; +import ResponsiveTableV2 from "@/components/features/whitepaper/mdx/ResponsiveTableV2.astro"; +import SiteSocials from "@/components/ui/SiteSocials.astro"; +import OrderedList from "@/components/features/whitepaper/mdx/OrderedList.astro"; +import Divider from "@/components/features/whitepaper/mdx/Divider.astro"; +import ChapterHeading from "@/components/features/whitepaper/mdx/ChapterHeading.astro"; +import Reference from "@/components/features/whitepaper/mdx/Reference.astro"; +import ReferenceMarker from "@/components/features/whitepaper/mdx/ReferenceMarker.astro"; + +

    + +_Dieses Whitepaper dient ausschließlich Informationszwecken und +stellt weder ein Angebot zum Verkauf noch eine Aufforderung zum Kauf noch eine +Empfehlung für Wertpapiere, Anlagen oder Finanzprodukte dar. Leserinnen und Leser sollten +eigene Sorgfalt walten lassen und qualifizierte Fachleute konsultieren, bevor sie +Anlageentscheidungen treffen. Quantus Network übernimmt keine Zusicherungen oder Gewährleistungen +hinsichtlich der Richtigkeit oder Vollständigkeit der hier enthaltenen Informationen._ + +

    + Inhalt +

    + + + +
    + + + +### Die Quantenbedrohung + +Klassische Blockchains stehen vor einer existenziellen Bedrohung durch +kryptographisch relevante Quantencomputer (CRQC). Die +kryptographischen Grundlagen von Blockchains beruhen auf der Schwierigkeit des +diskreten Logarithmusproblems (DLP), und Quantenalgorithmen, +insbesondere der von Shor, können das DLP exponentiell schneller lösen als +klassische Computer. Diese Schwachstelle könnte es quantenbezogenen Angreifern +ermöglichen, private aus öffentlichen Schlüsseln abzuleiten – womit sie +Transaktionen fälschen und sensible Finanzdaten +entschlüsseln könnten. + +> ohne proaktive quantenresistente Upgrades riskiert die Billionen-Dollar-Kryptoökonomie +> eine plötzliche Abwertung durch solche Angriffe. + +### Einzigartiges Wertversprechen + +Nach dem lateinischen Wort für „wie viel“ benannt, ermöglicht Quantus Network +skalierbares, quantensicheres, privates Geld. Quantus ist keine +allgemeine Smart-Contract-Plattform. Wie ein Restaurant mit wenigen +hoch verfeinerten Gerichten bietet Quantus: + +- Post-Quanten-Signaturen für alle Transaktionen +- Post-Quanten-Signaturen und -Verschlüsselung (ML-DSA und ML-KEM) zur Absicherung von Peer-to-Peer-Verbindungen +- Post-Quanten-Zero-Knowledge-Beweise zur Skalierung +- Hochsicherheitskonten, um Diebstahl zu erschweren und Fehlerkorrektur zu ermöglichen +- Lesbare Prüfsätze zur einfachen Adressverifikation + +Die Konzentration auf skalierbares, quantensicheres, privates Geld +ergibt sich aus der Bedrohung durch CRQC für die Branche und aus der Unfähigkeit von Bitcoin, +diese Herausforderungen zu adressieren. + + + +### Grundlagen des Quantencomputings + +Quantencomputer nutzen Prinzipien wie Superposition und +Verschränkung, um Berechnungen durchzuführen, die für +klassische Maschinen unhandelbar sind. Anders als klassische Bits, die 0 oder 1 sind, +können Qubits gleichzeitig in mehreren Zuständen existieren, +was für bestimmte Probleme exponentiellen Parallelismus ermöglicht. Diese +Fähigkeit birgt existenzielle Risiken für die kryptographischen Systeme, die +Blockchain-Finanzen tragen, da für Quantenhardware entwickelte Algorithmen die +Sicherheitsannahmen der meisten Public-Key-Kryptographie untergraben. + +**Shors Algorithmus**, 1994 von Peter Shor vorgestellt, liefert ein +polynomzeitverfahren zur Faktorisierung großer Ganzzahlen und zur Lösung des +diskreten Logarithmusproblems auf einem Quantencomputer. Er nutzt +Quanten-Fourier-Transformationen (QFT), um die Periode einer Funktion zu finden, +und kann damit effizient die Einwegfunktionen invertieren, auf denen +Verfahren wie RSA oder Elliptische-Kurven-Kryptographie (ECC) beruhen. Für +Blockchain-Finanzen bedeutet das: Ein Angreifer mit einem ausreichend leistungsfähigen Quantencomputer (geschätzt ~2.000 logische Qubits ) +könnte private aus öffentlichen Schlüsseln in polynomieller Zeit O(n³) ableiten – eine extreme Beschleunigung, +die verwundbare Systeme über Nacht obsolet macht. + +**Grovers Algorithmus**, 1996 von Lov Grover vorgeschlagen, liefert eine +quadratische Beschleunigung für unstrukturierte Suche und reduziert die +Suchzeit von O(n) auf O(√n) Operationen. Obwohl er für asymmetrische Kryptographie nicht so +verheerend ist wie Shor, betrifft Grover +symmetrische Primitive wie Hashfunktionen und AES-Verschlüsselung, +wodurch das Sicherheitsniveau effektiv halbiert wird (z. B. verhält sich ein 256-Bit-Schlüssel +gegenüber Quantenangriffen wie 128 Bit). Dieser Angriff wird +durch Verdopplung der Bit-Sicherheit statt durch einen Wechsel des +kryptographischen Schemas gemildert. Zudem ist Grovers quadratische Beschleunigung wegen hoher Qubit- und Gatteranforderungen +praktisch wenig relevant: Sie erfordert Milliarden sequenzieller Operationen bei begrenzter Parallelisierung, +was sie selbst mit zukünftiger Hardware für reale Investitionen unattraktiv macht. + +### Vier Bedrohungskategorien + +#### 01 - Digitale Signaturen fälschen + +Shors Algorithmus bedroht direkt die auf ECC basierenden Signaturen, die in +den meisten Blockchains verwendet werden (z. B. die Kurve secp256k1 bei Bitcoin), und erlaubt es +Angreifern, Nutzer zu imitieren und betrügerische +Transaktionen zu autorisieren. Eine solche Fähigkeit wäre ein kritisches Versagen +der grundlegendsten Eigenschaft einer Blockchain. + +#### 02 - Falsche Beweise in Zero-Knowledge-Systemen fälschen + +Viele Zero-Knowledge-Beweise, etwa zk-SNARKs für +datenschutzorientierte Finanzen, beruhen auf der Schwierigkeit des diskreten Logarithmus über +Elliptische-Kurven-Paarungen für Commitments. Shor könnte es ermöglichen, +ungültige Beweise zu erzeugen, die gültig erscheinen – womit ein Angreifer neue Coins prägen oder den Zustand von Layer-2-Lösungen (L2) fälschen könnte. + +#### 03 - Geheime Information entschlüsseln + +Quantenangriffe könnten durch verwundbare Public-Key-Schemata geschützte Daten in +Datenschutzprotokollen wie Zcash +oder Monero offenlegen. Sie könnten auch P2P-Kommunikation in Finanzprotokollen +entschlüsseln, sensible Vermögensdetails preisgeben und gezielten +Diebstahl ermöglichen. + +#### 04 - Hashfunktionen invertieren + +Grovers Algorithmus könnte Preimage-Angriffe auf Hashes wie +SHA-256 beschleunigen, die in Proof-of-Work und Adressgenerierung verwendet werden – das ist jedoch +die am wenigsten besorgniserregende Bedrohung. Viele +Post-Quanten-Kryptographie-Schemata nutzen hashbasierte Konstruktionen, da +Hashes mit ausreichend großem Digest als hinreichend sicher gelten. + +### Skalierungsherausforderungen in der Post-Quanten-Kryptographie + +Obwohl Post-Quanten-Kryptographie (PQC) wesentlichen Schutz +vor Quantenbedrohungen bietet, führt sie aufgrund des inhärenten Designs dieser Algorithmen zu +erheblichen Skalierungshindernissen. +Anders als Elliptische-Kurven-Verfahren, die auf kompakten mathematischen Strukturen beruhen, +benötigen PQC-Primitive größere Parameter, um die +Sicherheit gegen klassische und quantenbezogene Angreifer zu halten. Dadurch entstehen +deutlich größere öffentliche und private Schlüssel sowie Signaturen, +oft um Größenordnungen. Die folgende Tabelle +zeigt typische ML-DSA-Größen bei einer Post-Quanten-Sicherheit von 128 Bit +im Vergleich zu klassischen Äquivalenten wie 256-Bit-ECDSA: + + + +Größen bei Post-Quanten-Sicherheit von 128 Bit. Quelle: Open +Quantum Safe Project + +Wie zu sehen ist, können ML-DSA-Signaturen mehr als 70-mal größer sein als +vergleichbare ECDSA-Signaturen, öffentliche Schlüssel mehr als 80-mal. +Andere PQC-Familien verschärfen das: hashbasierte Schemata wie +SPHINCS+ können Signaturen bis zu 41 KB erzeugen, während größenoptimierte Gittervarianten +wie FALCON die klassischen Größen +weiterhin um ein Vielfaches übertreffen. + +In Blockchain-Kontexten summieren sich diese aufgeblähten Größen zu +systemischen Skalierungsproblemen. Größere Signaturen blähen einzelne +Transaktionen auf, senken die Transaktionen pro Sekunde (TPS), weil Blöcke +schneller voll werden und die Validierung länger dauert. Sie belasten auch die Peer-to-Peer-Kommunikation (P2P), erhöhen Bandbreite und +Propagationsverzögerungen und können das Risiko von Forks oder +Waisenblöcken in Konsensmechanismen wie Proof-of-Work erhöhen. +Auch die Speicheranforderungen steigen, mit höheren Betriebskosten für Knoten und Hürden für die Teilnahme, insbesondere für +Nutzer oder Validatoren mit begrenzten Ressourcen. + + + Diese Skalierungsherausforderungen müssen künftig alle Blockchains angehen. + Bitcoin hätte zum Beispiel deutlich weniger als 1 TPS, wenn die maximale + Blockgröße nicht erhöht würde. + + + + +### Das Koordinationsproblem + +Die konservative Kultur von Bitcoin lehnt Protokolländerungen ab. Jede PQC-Verbesserung +würde Konsens zu kontroversen Fragen wie Migrationsfristen, +möglichem Coin-Beschlagnahme und Erhöhungen der Blockgröße erfordern. +Selbst wenn die Community zustimmte, müsste jeder Nutzer +seine Coins auf neue quantensichere Adressen migrieren. +Die Migration erfordert Handeln aller Krypto-Inhaberinnen und -Inhaber, +von denen viele den Zugang zu Wallets verloren haben oder die +Bedrohung ignorieren. + +Diese Probleme bestehen in jeder öffentlichen Blockchain, sind für Bitcoin aber besonders +schwer wegen fehlender klarer Führung und einer +Philosophie technischer Versteinerung. + +### Das Problem verlorener Coins + +Schätzungen zufolge sind zwischen 250 und 500 Milliarden US-Dollar in Bitcoin +dauerhaft unzugänglich wegen verlorener Schlüssel, verstorbener Inhaber oder +vergessener Wallets. [3] Diese Coins können nicht migriert werden und wirken wie eine +öffentliche Belohnung für den Bau eines kryptographisch relevanten Quantencomputers (CRQC). Quantenangreifer werden private Schlüssel +aus nicht migrierten öffentlichen Schlüsseln ableiten und vermutlich Milliarden +an BTC auf den Markt drücken. + +> die einzige technische Lösung erfordert eine strikte Frist, +> die nicht migrierte Coins einfriert – eine +> politische Unmöglichkeit. + +Ohne eine solche Frist werden nicht migrierte Coins +gestohlen und verkauft, der Markt gedrückt und das +Vertrauen in das Netz zerstört. + +### Das Problem des Migrationszeitplans + +Post-Quanten-Signaturen sind 20- bis 80-mal größer als die aktuellen Bitcoin-Signaturen. +Ohne grundlegende Architekturänderungen bricht die Leistung von Bitcoin +auf einen Bruchteil seiner ohnehin begrenzten Kapazität ein. + +Selbst wenn Bitcoin die politischen und technischen Hürden löst, würde +die Migration selbst Monate oder Jahre dauern. Jede Inhaberin und jeder Inhaber muss +mindestens eine Transaktion senden, um Mittel auf eine quantensichere Adresse zu verschieben. +Viele werden zuerst Testtransaktionen senden. Während aufgeblähte PQC-Signaturen die Leistung erdrücken, entsteht eine Warteschlange über +Monate oder Jahre, während weiterhin verwundbare Coins exponiert sind. + + + Diese sich stapelnden Herausforderungen machen es außerordentlich schwer, + Quantensicherheit zu bestehenden Ketten hinzuzufügen. Quantus Network + vermeidet das, indem es Quantensicherheit von Tag eins in die Kette + integriert. + + + + +### Grundlagen + +Quantus Network basiert auf Substrate, einem Blockchain-SDK, +entwickelt von Parity Technologies, dem Team hinter Ethereum und +Polkadot. Substrate ist hochgradig modular, sodass Komponenten leicht ausgetauscht werden können, um den Fokus auf das zu legen, was Quantus einzigartig macht. + +Quantus erweitert Substrate: + +- durch Unterstützung für Post-Quanten-Signaturschemata +- durch Aktualisierung der P2P-Netzwerksicherheit auf Post-Quanten +- durch hinzugefügte, nutzergesteuerte Transaktionsumkehrbarkeit +- durch ZK-kompatible Datenbank, indem alle Datentypen an + Feldelement-Grenzen ausgerichtet werden + +### Post-Quanten-kryptographische Primitive + +Quantus Network setzt vom NIST standardisierte PQC ein, um +Transaktions- und Netzwerkkommunikationssicherheit gegen +Quantenbedrohungen zu gewährleisten. Im Kern der Transaktionsintegrität steht **ML-DSA** +(Module-Lattice-Based Digital Signature Algorithm, zuvor +CRYSTALS-Dilithium), ein gitterbasiertes Signaturschema, das für sein Gleichgewicht aus Sicherheit, Effizienz und Implementierbarkeit gewählt wurde. ML-DSA nutzt die Schwierigkeit von Problemen wie +Learning With Errors (LWE) und Short Integer Solution (SIS) über +Modulgittern und bietet robusten Widerstand gegen klassische und +quantenbezogene Angriffe, einschließlich Shors Algorithmus. + +Für Transaktionssignaturen integriert Quantus **ML-DSA-87**, den Parametersatz +mit der höchsten Sicherheitsstufe (NIST Level 5, +äquivalent zu 256 Bit klassisch und 128 Bit quantenbezogen), +um mögliche Fortschritte in der Gitter-Kryptoanalyse abzufedern. Diese Wahl priorisiert Vorsicht, da Gitter-Kryptographie relativ neu und weniger kampferprobt ist als klassische Schemata. +Größere Parameter mildern Risiken potenzieller Fortschritte +in der Gitter-Kryptoanalyse, die kleinere Schlüsselgrößen +weiterhin als schwächere Ziele lassen würden. + +#### In Betracht gezogene Alternativen + +ML-DSA wurde gegenüber Alternativen wie FN-DSA (Falcon) gewählt wegen der höheren Implementationskomplexität von FN-DSA (z. B. erfordert +Gleitkommaoperationen, wenig geeignet für Blockchain), fehlender deterministischer Schlüsselerzeugung in der Spezifikation und des zum Entwicklungszeitpunkt nicht +finalisierten Status. + +Hashbasierte Optionen wie SLH-DSA wurden wegen noch größerer Signaturen +(über 17 KB) nicht gewählt. Krypto-Agilität +(die Fähigkeit, Signaturschemata auszutauschen) ist in +Substrate integriert, sodass diese Alternativen künftig relativ einfach ergänzt werden können, +wenn die Umstände es erfordern. + +Obwohl ML-DSA-87 größere Schlüssel und Signaturen erzeugt, sind sie +im frühen Quantus-Netz handhabbar, wo Speicher noch kein +Engpass ist, und Optimierungen wie Wormhole-Adressen mittels +Zero-Knowledge-Beweisen werden das Skalieren adressieren. + +Technische Implementierungsdetails siehe [QIP-0006](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0006.md). + +### LibP2P – Quantensicheres Netzwerk + +Quantus Network sichert Peer-to-Peer-Kommunikation (P2P) +durch Kombination von ML-DSA zur Authentifizierung +und **ML-KEM** (Module-Lattice-Based Key-Encapsulation Mechanism, +zuvor CRYSTALS-Kyber) zur Verschlüsselung. Diese Integration erweitert PQC auf den libp2p-Stack und modifiziert +Kernkomponenten für Quantenresistenz: ML-DSA-87-Signaturen +für Peer-Identität und ML-KEM-768 für Transportsicherheit +(Erweiterung des Noise-Handshakes um eine zusätzliche KEM-Nachricht +für quantenresistente gemeinsame Geheimnisse). + +Die P2P-Schicht wird in Quanten-Sicherheitsanalysen oft vernachlässigt. +Peer-Authentifizierung ist wichtig, aber das Schlimmste, was ein Angreifer +auf P2P-Ebene tun kann, ist einen Knoten zu imitieren und ungültige Nachrichten zu senden, +was Denial-of-Service verursachen könnte. Dieser Angriff wird bereits +gemildert, weil Knoten im Blockchain-Modell in der Regel nicht vertrauenswürdig sind und +bei Erkennung leicht den Schlüssel wechseln können. Ebenso bietet das Entschlüsseln von P2P-Kommunikation +dem Angreifer begrenzte Vorteile (z. B. Transaktionspfade verfolgen, +mit Proxies oder Tor milderbar), und die meisten Daten werden öffentlich auf der +Kette sichtbar. + +Dennoch schützt die quantensichere Absicherung der P2P-Schicht vor +Abhören, Man-in-the-Middle-Angriffen und Quanten-Entschlüsselung +und stellt sicher, dass Node-Gossip, Blockpropagation und +andere Netzwerkinteraktionen in absehbarer Zeit vertraulich und integer +bleiben. + +Technische Details siehe [QIP-0004](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0004.md). + +### PQC-Skalierung – Wormhole-Adressen + +Um die der Post-Quanten-Kryptographie innewohnenden Skalierungsherausforderungen anzugehen, führt Quantus Network ein innovatives aggregiertes Post-Quanten-Signaturschema namens **„Wormhole Addresses“** ein. +Dieses System nutzt Zero-Knowledge-Beweise (ZKP), +erzeugt mit dem Beweissystem Plonky2 (im Wesentlichen STARKs), um +Saldo-Verifikation off-chain zu verlagern, sodass die Kette +einen einzigen kompakten Beweis verifizieren kann, ohne einzelne Signaturen zu verarbeiten. +Wormhole Addresses ermöglichen die Verifikation vieler +Transaktionen mit einem Beweis; die öffentlichen Inputs (z. B. Nullifiers, +Speicher-Root, Ausgangsadressen und Beträge) sind der Haupt- +Engpass. Dadurch sinken die amortisierten Speicheranforderungen pro Transaktion +auf etwa 256 zusätzliche Bytes pro Transaktion, +weit unter jedem bekannten PQC-Signaturschema. + +Die Quantensicherheit des Schemas kommt vom Einsatz der sicheren Hashfunktion +**Poseidon2** für Commitments über FRI (Fast +Reed-Solomon Interactive Oracle Proofs) statt der in SNARKs üblichen, +quantenverwundbaren Elliptische-Kurven-Paarungen. + +Außerdem bleiben Authentifizierungsgeheimnisse hinter +Poseidon2 verborgen. Da sichere Hashfunktionen durch Grovers Algorithmus nur quadratisch +geschwächt werden, brechen sie nicht; Hash-Preimage-Beweise +können als leichte Post-Quanten-Signaturen in ZK-Kontexten dienen, +ähnlich hashbasierten Schemata wie SPHINCS+. + +#### Client-/Prover-Flow + +Nutzer erzeugen eine nachweislich nicht ausgebende Adresse durch doppeltes Hashen eines Salzes +zusammen mit einem Geheimnis: + +``` +H(H(salt|secret)) +``` + +Diese Konstruktion vermeidet Fehlalarme (z. B. Verwechslung einer einfachen Hash-Public-Key +mit einer nicht ausgebenden Adresse), weil in Substrate +(und allgemein) Blockchain-Adressen der einfache Hash eines +aus dem privaten Schlüssel algebraisch abgeleiteten öffentlichen Schlüssels sind, +nicht ein sicherer Hash. Die Sicherheit der Konstruktion +reduziert sich damit auf das Finden der Preimage-zur-Preimage eines +sicheren Hashs. An diese Adresse gesendete Tokens werden faktisch verbrannt. +Sie können nicht ausgegeben werden, weil es keinen privaten Schlüssel für die +empfangende Adresse gibt. Diese Coins können neu geprägt werden, +ohne das Angebot zu inflieren. + +Für jede Übertragung wird ein Speicherobjekt TransferProof erstellt, +mit Details wie einer global eindeutigen Transferanzahl. Das Nutzer-Wallet +erzeugt einen Merkle-Patricia-Trie (MPT)-Speicherbeweis von der +Speicher-Root eines aktuellen Block-Headers bis zum Blatt dieses TransferProof. +Ein Nullifier wird berechnet, um Doppelausgaben zu verhindern: + +``` +H(H(salt | secret | global_transfer_count)) +``` + +#### Aggregator-Flow + +Jede Partei (Client, Miner oder Dritte) kann mehrere +Beweise mittels Plonky2-Rekursion aggregieren und einen Beweisbaum bilden, in dem +jeder Elternbeweis die Kinder verifiziert und die öffentlichen Kind-Inputs aggregiert: + +- Nullifiers passieren unverändert +- Ausgangsadressen werden dedupliziert +- Block-Hashes werden verknüpft nachgewiesen und dann bis auf den neuesten verworfen +- Beträge für doppelte Ausgangsadressen werden summiert + +#### Chain-/Verifier-Flow + +Das Netzwerk verifiziert den aggregierten Beweis durch Prüfung: Block-Hash +ist in der Kette und aktuell, Eindeutigkeit des Nullifiers (gegen Doppelausgabe) +und Gültigkeit des Beweises. Der ZK-Schaltkreis erzwingt Korrektheit des Speicherbeweises, +Genauigkeit des Nullifiers, Nicht-Ausgebbarkeit der Adresse, +Übereinstimmung der Salden zwischen Ein- und Ausgängen und +Verkettung der Block-Header. + +#### Warum Plonky2 + +- Bereits auditiert +- Post-quantenfest +- Ohne trusted setup +- Effizientes Beweisen/Verifizieren +- Flüssige Beweisaggregation +- Native Rust-Implementierung +- Kompatibel mit Substrates no-std-Umgebung + + + Rekursive Beweise enden in 170 Millisekunden mit kompakten Größen (100 KB pro + aggregiertem Beweis). Im optimalen Fall mit 5-MB-Blöcken und allen + Transaktionen zur gleichen Ausgabe könnten Wormhole Addresses ~153.000 + Transaktionen in einem Block bündeln (4,9 MB / 32 Bytes pro Nullifier): eine + Verbesserung um den Faktor 223 gegenüber ~685 rohen ML-DSA-Transaktionen (5 MB + / 7,3 KB je Transaktion). + + +#### Sicherheitshinweise + +Potenzielle Risiken umfassen Inflationsfehler durch fehlerhafte Schaltkreis-/Verifikationsimplementierungen, +die jedoch wirtschaftlich erkennbar wären, wenn +neu geprägte Coins die Salden von Null-Sende-Adressen übersteigen. Nutzer können optional nachweisen, dass eine Adresse eine Wormhole-Adresse ist, indem sie den +ersten Hash ohne Offenlegung des Geheimnisses veröffentlichen. Verifikationstransaktionen sind nicht +signiert, daher muss DoS durch fehlgeschlagene Transaktionen +ohne finanzielle Mittel gemildert werden. Token-Supply-Berechnungen bleiben +konsistent, da Neu-Prägungen als neue Coins erscheinen, aber durch Verbrennungen +maximale Supply-Garantien erhalten. + +Weitere technische Details siehe [QIP-0005](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0005.md). + +### Konsensmechanismus + +Quantus Network verwendet einen Proof-of-Work (PoW)- +Konsensalgorithmus, der die wünschenswerten Eigenschaften des Bitcoin-Konsenses bewahrt +und die Kompatibilität mit ZK-Beweissystemen verbessert, indem +SHA-256 durch **Poseidon2** ersetzt wird. + +Wichtig: Diese Änderung erfolgt nicht wegen Quantensicherheit. +Kryptographische Hashfunktionen wie SHA-256 werden durch Quantenalgorithmen, insbesondere Grover, geschwächt, aber nicht zerstört. +Einige Post-Quanten-Signaturschemata nutzen aus diesem Grund sichere Hashes als Grundbaustein. + +Poseidon2 ist eine Verfeinerung der Hashfunktion Poseidon. SNARKs oder STARKs für Berechnungen mit traditionellen Hashes +wie SHA-256 zu erstellen erfordert typischerweise fast 100-mal mehr +Gatter als mit Poseidon, das vollständig auf +algebraischen Feldoperationen statt Bitoperationen beruht. + +Wir verwenden das **Goldilocks-Feld** für Poseidon2 und Plonky2. Die Ordnung des +Goldilocks-Feldes passt in eine 64-Bit-Unsigned-Integer, +was die Effizienz erhöht, ohne die Solidität zu gefährden. + + + +Beim Umgang mit Kryptowährungsschlüsseln gibt es viele Risiken. Die meisten +lassen sich vermeiden. + +### Umkehrbare Transaktionen + +Quantus Network bietet nutzerkonfigurierbare umkehrbare Transaktionen. +Absender legen ein Zeitfenster fest, in dem sie ausgehende Überweisungen +stornieren können. Das erschwert Diebstahl und korrigiert Fehler, ohne die +Finalität zu opfern. Das System nutzt ein modifiziertes Substrate-„Scheduler“-Pallet +mit Zeitstempeln. Wallets zeigen Countdowns für Absender +(mit Stornieren-Button) und Empfänger. + +Umkehrbare Transaktionen ermöglichen neuartige Sicherheitsprotokolle bei +dezentraler Anwendung on-chain. + +Weitere technische Details siehe [QIP-0009](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0009.md). + +### Prüfsätze + +Quantus Network führt „Check-Phrases“ ein – eine lesbare, kryptographisch +sichere Prüfsumme für Blockchain-Adressen. Die Adresse wird gehasht, um eine kurze Folge merkbarer Wörter aus der +BIP-39-Mnemonik-Liste zu erzeugen. Prüfsätze schützen +vor Tippfehlern, Manipulation und Address-Poisoning-Angriffen. Eine Schlüsselableitungsfunktion mit 50.000 Iterationen +macht Rainbow-Table-Angriffe teuer. Bei großen Transaktionen sollten Nutzer weiterhin jedes +Zeichen der Adresse prüfen. + +Weitere technische Details siehe [QIP-0008](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0008.md). + +### Hochsicherheitskonten + +Jedes Konto kann zu einem „Hochsicherheitskonto“ mit +verpflichtenden Revertierungsperioden für alle ausgehenden Überweisungen aufgewertet werden. Ein benannter **Guardian** +(Hardware-Wallet, Multisig oder vertrauenswürdige Dritte) kann +verdächtige Transaktionen während der Revertierungsperiode stornieren und +Mittel an den Guardian statt an Absender oder Empfänger senden. Diese Opt-in-Funktion ist nach Aktivierung dauerhaft und verhindert, dass Diebe sie deaktivieren. + +Guardians können verkettet werden: Der Guardian eines Hochsicherheitskontos kann +selbst ein Hochsicherheitskonto mit eigenem Guardian sein. So entstehen +komponierbare Hierarchien, in der jeder Guardian höhere Befugnisse über das +geschützte Konto hat. Das Design gibt Nutzern Zeit, unbefugte Aktivität zu erkennen und zu reagieren, ohne +die Finalität legitimer Überweisungen zu gefährden. + +Weitere technische Details siehe [QIP-0011](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0011.md). + +### Schlüsselwiederherstellung + +Viele Krypto-Vermögen sind mit ihren Besitzern ins Grab gegangen. +Quantus Network bietet eine einfache Möglichkeit, eine Wiederherstellungsadresse anzugeben, +die jederzeit Mittel abheben kann, vorbehaltlich einer festen Verzögerung. In dieser Zeit +kann der Eigentümer die Wiederherstellung ablehnen, wenn er noch Zugriff auf den +Schlüssel hat. Diese Funktion ermöglicht Überleben: Nutzer haben ein On-Chain-Testament +ohne Gerichte oder formale Erbfolge. + +### HD-Lattice + +Hierarchisch-deterministische (HD) Wallets sind der Branchenstandard +für Blockchains und erlauben, eine einzige Seed-Phrase für alle +Schlüssel zu sichern – mit besserer Sicherheit und Komfort gegenüber manuellen Kopien pro +Aktion. Die Übertragung auf Gitterschemata wie Dilithium wirft zwei +Herausforderungen auf: + +- HMAC-SHA512-Ausgaben können nicht direkt private Gitterschlüssel bilden, + die Polynome aus einem Ring mit bestimmten + Eigenschaften sind. +- Nicht gehärtete Schlüsselableitung beruht auf Elliptische-Kurven-Addition, + die in Gittern fehlt (öffentliche Schlüssel sind unter keiner algebraischen Operation abgeschlossen). + +Quantus Network löst den ersten Punkt, indem die HMAC-Ausgabe als Entropie dient, um den privaten Schlüssel deterministisch zu konstruieren, +nicht als den Schlüssel selbst. Der zweite Punkt ist weniger kritisch und +bleibt eine offene Forschungsfrage, ob sich Gitter-Kryptographie +so anpassen lässt, dass er gelöst wird. + +Weitere technische Details siehe [QIP-0002](https://github.com/Quantus-Network/improvement-proposals/tree/main/qip-0002). + + + +Quantus Network operiert in einem sich wandelnden Umfeld; wir können +nicht davon ausgehen, beim ersten Versuch alles richtig zu machen. Daher wählen wir einen +einfachen Ausgangspunkt und erlauben dem Governance-System, +Änderungen vorzunehmen, sobald neue Erkenntnisse vorliegen. Dieses Design macht die Blockchain zu einer lebendigen Entität, die sich +an ihre Umgebung anpassen kann. Insbesondere erlaubt der Substrate-Governance-Prozess +tiefgreifende On-Chain-Änderungen mit minimaler Koordination +zwischen den verschiedenen Knotenbetreibern. + +### Blockbelohnungen + +Quantus Network nutzt ein einfaches Tokenomics-Modell nach Bitcoin-Vorbild. Es gibt ein maximales Angebot von **21.000.000 Coins** und eine einfache Heuristik +bestimmt die Blockbelohnung: + +``` +block_reward = (max_supply - current_supply) / constant +``` + +Diese Heuristik bildet eine sanft fallende Exponentialkurve, während die +block_reward zum current_supply beiträgt und damit die im nächsten Block berechnete +block_reward senkt. Gebühren- und andere Verbrennungen reduzieren das current_supply und werden Teil des +Blockbelohnungsbudgets. Die Konstante ist so gewählt, dass ohne +jegliche Verbrennung etwa 99 % der Coins in etwa 30 +Jahren ausgegeben werden. + +### Zuordnung an Investoren + +Quantus Network wurde mit Hilfe von Investoren aufgebaut, die hohes Risiko +bei der Finanzierung trugen. Private Investoren unterliegen einem 4-Jahres-Vesting, +wie das Team. Investoren aus dem öffentlichen Verkauf erhalten am ersten Tag volle Liquidität. Die im öffentlichen Verkauf eingenommenen Mittel werden +mit Tokens gepaart und für Liquidität (DEX, CEX und Market +Maker) verwendet. Diese Investorenzuordnungen zusammen mit der Liquidität bilden den einzigen „Pre-Mine“. Der Rest der Tokens muss geschürft werden, bis +das volle Angebot erreicht ist. + +Wird weniger als das Maximum von 10 % während des +öffentlichen Verkaufs verkauft, erfolgt eine proportionale Reduktion der Liquiditäts-Tokens und der Rest wird Minern über Blockbelohnungen ausgegeben. + +### Zuordnung an das Unternehmen + +Um das Team für das Risiko des Aufbaus neuer Technologie +ohne Erfolgsgarantie zu entschädigen, geht ein Teil der Blockbelohnung über etwa vier Jahre an das +Unternehmen. Das entspricht faktisch einem Vesting von etwa **15 % des Gesamtangebots** für das Unternehmen. + +Danach kann der Unternehmensanteil an Blockbelohnungen +abgeschaltet, angepasst oder per Token-Inhaber-Vote umgeleitet werden. + +### Transaktionsgebühren + + + +### Fork-freie Upgrades + +Quantus Network unterstützt „fork-freie“ Upgrades über +Substrate-Runtime-Upgrades, sodass die Kern-Blockchain-Logik +(die „Runtime“) ohne störende Hard Forks oder Spaltung der +Community evolvieren kann. Das gelingt durch On-Chain-Governance-Referenden, bei denen genehmigte Vorschläge einen Runtime-Swap auslösen +– im Wesentlichen wird der bestehende WASM-Code-Blob in einem +einzigen Block durch einen neuen ersetzt, mit Erhalt von Zustand und +Betrieb. Dieser Weg minimiert Ausfallzeiten und Risiken und +ermächtigt die Community, das Protokoll iterativ zu verfeinern, wenn der echte Nutzungsfall Verbesserungen zeigt. + +Wenn die Community Vertrauen ins System gewinnt, wird die +Macht, die Runtime zu ändern, deutlich reduziert, um die +Angriffsfläche zu begrenzen, falls ein böswilliger Akteur die Kontrolle über den +Upgrade-Prozess erlangt. + +### Governance-System + +Quantus Network übernimmt sein Governance-Rahmenwerk vom +OpenGov-System von Polkadot über Substrate. Token-Inhaber +nehmen per **Conviction Voting** teil und sperren ihre +Assets für unterschiedlich lange Zeiträume, um das Stimmgewicht zu verstärken. Die Verstärkung reicht von 1× (ohne Sperre) bis 6× (maximale Sperre). +Dieses Design fördert langfristige Ausrichtung, indem Einfluss an +Commitment gebunden wird. + +Vorschläge werden in mehrere Abstimmungsspuren („Origins“) eingeteilt. +Jeder Origin hat maßgeschneiderte Parameter wie Zustimmungsschwellen +(z. B. qualifizierte Mehrheit für hochimpactige Änderungen), Mindestdepots gegen Spam, Vorbereitungs-/Ausführungsperioden und +Entscheidungsfristen gegen Blockaden. Dieses Mehrspur-Design +erlaubt parallele Referenden – von routinemäßigen Treasury-Ausgaben +bis zu kritischen Runtime-Upgrades. + +Das **Technical Collective** ist eine kuratierte Gruppe technischer Expertinnen und Experten, +die als Spezialorgan für dringende technische Angelegenheiten vorschlägt, prüft oder whitelistet und sie über eine +dedizierte Spur beschleunigt, bei gemeinschaftlicher Aufsicht. + +Quantus übernimmt dieses System unverändert, startet aber mit einer +minimalen Konfiguration, um früh Komplexität zu vermeiden. Zunächst ist +nur die Spur des Technical Collective aktiv, genutzt für +verbindliche Hochprivileg-Entscheidungen wie Protokoll-Upgrades oder +Parameteranpassungen. + +Später kann Quantus eine nicht verbindliche Community-Abstimmungsspur hinzufügen, um +Stimmungen zu nicht durchsetzbaren Themen zu erfassen, etwa Feature-Vorschläge +oder Ökosystem-Umfragen. Dieses System wird verbindlich, +wenn das Unternehmen das Netz an die DAO übergibt. Dieser phasenweise Ansatz +erlaubt organisches Wachstum des Netzes durch künftige Governance-Votes, +ohne Nutzer am Anfang mit unnötiger Komplexität zu belasten. + + + +Die aktuelle Roadmap bis 2026, vorbehaltlich Änderungen. + + + + + + + + + + + + + + + +
    + + + +Den Aufbau von Quantus Network begleiten inhärente Risiken. + +### Implementierungsprobleme + +Fehler in der Softwarelogik können selbst in den besten +designten Systemen schwere Ausfälle verursachen. + +### Probleme bei der NIST-Algorithmenauswahl + +Potenzielle Fehler oder Hintertüren in ausgewählten Post-Quanten-Standards +(z. B. ML-DSA, ML-KEM), die nach der Standardisierung auftauchen könnten. Im +schlimmsten Fall würden solche Fehler es einem Angreifer erlauben, Signaturen zu fälschen, +indem er den privaten aus dem öffentlichen Schlüssel ableitet – ein +katastrophaler Kettenfehlmodus. Wenn solche Fehler öffentlich werden, könnte Quantus Network auf einen neuen Algorithmus upgraden, +doch bei seltener Ausnutzung werden sie +vielleicht nie entdeckt. + +### Zeitrahmen des Quantencomputings + +Quantenfortschritte könnten viel später kommen als erwartet +und die PQC-Notwendigkeit verzögern; umgekehrt könnte geheime Entwicklung (z. B. +durch Regierungen) plötzliche Bedrohungen erzeugen, wenn die Blockchain-Community +nicht schnell genug upgraded. + +### Sonstige Überlegungen + +Allgemeine Adoptionsbarrieren, regulatorische Unsicherheit in +Finanzen/Blockchain und die inhärente Volatilität von Krypto-Ökosystemen. + + + +
    + + + Shor, P. W. (1997). Polynomial-time algorithms for prime factorization and + discrete logarithms on a quantum computer. _SIAM Journal on Computing_, 26(5), + 1484–1509. https://doi.org/10.1137/S0097539795293172 + + + + Grover, L.K. (1996). A fast quantum mechanical algorithm for database search. + _Proceedings of the Twenty-Eight Annual ACM Symposium on Theory of Computing_, + 212-219. https://doi.org/10.1145/237814.237866 + + + + Chainalysis. (2024). _The Chainalysis 2024 Crypto Crime Report_. + https://www.chainalysis.com/blog/2024-crypto-crime-report-introduction/ + + + + National Institute of Standards and Technology. (2024). _FIPS 204: + Module-Lattice-Based Digital Signature Standard (ML- DSA)_. U.S. Department of + Commerce. https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf + + + + National Institute of Standards and Technology. (2024). _FIPS 203: + Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)_. U.S. + Department of Commerce. + https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf + + + + Häner, T., Jaques, S., Naehrig, M., Roetteler, M., & Soeken, M. (2020). + Improved quantum circuits for elliptic curve discrete logarithms. + _arXiv:2002.12480_. https://arxiv.org/abs/2002.12480 + + + + Gidney, C., & Ekerå, M. (2021). _How to factor 2048 bit RSA integers in 8 + hours using 20 million noisy qubits_. _arXiv:1905.09749_. + https://arxiv.org/abs/1905.09749 + + + + Aggarwal, D., et al. (2021). Assessment of Quantum Threat To Bitcoin and + Derived Cryptocurrencies. _ePrint IACR_. https://eprint.iacr.org/2021/967.pdf + + + + Roetteler, M., Naehrig, M., Svore, K. M., & Lauter, K. (2017). Quantum + resource estimates for computing elliptic curve discrete logarithms. + _arXiv:1706.06752_. https://arxiv.org/abs/1706.06752 + + + + Open Quantum Safe Project. (n.d.). ML-DSA | Open Quantum Safe. Retrieved + January 29, 2026, from + https://openquantumsafe.org/liboqs/algorithms/sig/ml-dsa.html + diff --git a/website/src/contents/whitepapers/en-US/v0.3.3.mdx b/website/src/contents/whitepapers/en-US/v0.3.3.mdx new file mode 100644 index 0000000..c13895f --- /dev/null +++ b/website/src/contents/whitepapers/en-US/v0.3.3.mdx @@ -0,0 +1,880 @@ +--- +title: "Quantus Network Whitepaper" +version: "0.3.3" +publishedDate: "2026-03-21" +updatedDate: "2026-03-21" +authors: ["Christopher Smith"] +changelog: + - "Major revision: Legal Disclaimer, Contents, numbered chapters (01–09), PDF cover, TOC; References & Further Reading replaces Closure." + - "New chapter: The Migration Crisis (coordination, lost coins, PQC migration timeline)." + - "Introduction and quantum-threat sections rewritten: CRQCs framing, four numbered threat categories, inline citations." + - "Architecture and technical sections expanded or clarified (Foundation/Substrate, LibP2P, wormhole/Plonky2, consensus/Goldilocks field)." + - "Roadmap: Bell Mainnet Q2 2026; Fermi Upgrade Q4 2026; Planck Beta adds ZK integration." +pdfCover: true +# Astro `render().headings` skips JSX `

    ` and ChapterHeading; anchor slugs match markdown `###` ids. +toc: + insertBefore: + the-quantum-threat: + - slug: legal-disclaimer + text: Legal Disclaimer + - slug: contents + text: Contents + - slug: chapter-01 + text: Introduction + quantum-computing-basics: + - slug: chapter-02 + text: The Quantum Threat to Blockchain + the-coordination-problem: + - slug: chapter-03 + text: The Migration Crisis + foundation: + - slug: chapter-04 + text: Quantus Network Architecture + reversible-transactions: + - slug: chapter-05 + text: Wealth Preservation + block-rewards: + - slug: chapter-06 + text: Tokenomics and Governance + implementation-issues: + - slug: chapter-07 + text: Roadmap + - slug: chapter-08 + text: Risks + insertAfter: + other-considerations: + - slug: chapter-09 + text: References & Further Reading +--- + +import CalloutV2 from "@/components/features/whitepaper/mdx/CalloutV2.astro"; +import Figure from "@/components/features/whitepaper/mdx/Figure.astro"; +import Grid from "@/components/features/whitepaper/mdx/Grid.astro"; +import Column from "@/components/features/whitepaper/mdx/Column.astro"; +import TimelineV2 from "@/components/features/whitepaper/mdx/TimelineV2.astro"; +import ResponsiveTableV2 from "@/components/features/whitepaper/mdx/ResponsiveTableV2.astro"; +import SiteSocials from "@/components/ui/SiteSocials.astro"; +import OrderedList from "@/components/features/whitepaper/mdx/OrderedList.astro"; +import Divider from "@/components/features/whitepaper/mdx/Divider.astro"; +import ChapterHeading from "@/components/features/whitepaper/mdx/ChapterHeading.astro"; +import Reference from "@/components/features/whitepaper/mdx/Reference.astro"; +import ReferenceMarker from "@/components/features/whitepaper/mdx/ReferenceMarker.astro"; + +

    + +_This whitepaper is provided for informational purposes only and +does not constitute an offer to sell, a solicitation of an offer to buy, +or a recommendation for any security, investment, or financial +product. Readers should conduct their own due diligence and +consult with qualified professionals before making any investment +decisions. Quantus Network makes no representations or warranties +regarding the accuracy or completeness of the information herein._ + +

    + Contents +

    + + + +
    + + + +### The Quantum Threat + +Traditional blockchains face an existential threat from +cryptographically relevant quantum computers (CRQCs). The +cryptographic foundations of blockchains rely on the hardness of +the discrete logarithm problem (DLP), and quantum algorithms, +notably Shor's, can solve the DLP exponentially faster than +classical computers. This vulnerability could enable quantum- +adversaries to derive private keys from public keys, which would +allow them to forge transactions and decrypt sensitive financial +data. + +> without proactive quantum-resistant upgrades, the +> trillion-dollar crypto economy risks sudden +> devaluation from such attacks. + +### Unique Value Proposition + +Named after the Latin word for "how much", Quantus Network +enables scalable, quantum-secure, private money. Quantus is not a +general purpose smart contract platform. Like a restaurant with a +few highly perfected menu items, Quantus delivers: + +- Post-quantum signatures for all transactions +- Post-Quantum signatures and encryption (ML-DSA and ML-KEM) to secure peer connections +- Post-Quantum zero-knowledge-proofs to scale +- High Security Accounts to deter theft and enable recovery from mistakes +- Human-Readable check-phrases for easy address verification + +The decision to focus on scalable, quantum-secure, private money +stems from the threat CRQCs present to the industry and Bitcoin's +inability to address these challenges. + + + +### Quantum Computing Basics + +Quantum computers leverage principles like superposition and +entanglement to perform computations that are intractable for +classical machines. Unlike classical bits, which are either 0 or 1, +quantum bits (qubits) can exist in multiple states simultaneously, +enabling exponential parallelism for certain problems. This +capability poses existential risks to the cryptographic systems +underpinning blockchain finance, as algorithms developed for +quantum hardware undermine the security assumptions of most +public-key cryptography. + +**Shor's algorithm**, introduced in 1994 by Peter Shor, provides a +polynomial-time method for factoring large integers and solving the +discrete logarithm problem on a quantum computer. It exploits +Quantum Fourier Transforms (QFT) to find the period of a function, +allowing efficient reversal of the trapdoor functions that underlie +schemes like RSA or elliptic curve cryptography (ECC). For +blockchain finance, this means an attacker with a sufficiently +powerful quantum computer (estimated at ~2,000 logical qubits ) +could derive private keys from public keys in polynomial time O(n³) — an extreme +speed-up rendering vulnerable systems obsolete overnight. + +**Grover's algorithm**, proposed by Lov Grover in 1996, offers a +quadratic speedup for unstructured search problems, reducing +search time from O(n) to O(√n) operations. While not as +devastating as Shor's for asymmetric cryptography, Grover's +impacts symmetric primitives like hash functions and AES +encryption, effectively halving the security level (e.g., a 256-bit key +behaves like 128 bits against quantum attacks). This attack is +mitigated by simply doubling the security bits, rather than changing +the cryptographic scheme. Additionally, Grover's quadratic +speedup is impractical due to its high qubit and gate requirements, +requiring billions of sequential operations with limited +parallelization, making it infeasible for real-world reversals even on +future hardware. + +### Four Threat Categories + +#### 01 - Forging Digital Signatures + +Shor's algorithm directly threatens ECC-based signatures used in +most blockchains (e.g., Bitcoin's secp256k1 curve), allowing +adversaries to impersonate users and authorize fraudulent +transactions. Such a capability would represent a critical failure of +the most basic feature of a blockchain. + +#### 02 - Forging False Proofs in Zero-Knowledge Systems + +Many zero-knowledge proofs, such as those in zk-SNARKs for +privacy-focused finance, rely on discrete logarithm hardness via +elliptic-curve pairings for commitments. Shor's could enable the +creation of invalid proofs that appear valid, which could allow an +attacker to mint new coins or falsify the state of Layer-2s (L2s). + +#### 03 - Decrypting Secret Information + +Quantum attacks could expose encrypted data protected by +vulnerable public-key schemes in privacy protocols such as Zcash +or Monero. It could also decrypt p2p communications in financial +protocols, revealing sensitive wealth details and enabling targeted +theft. + +#### 04 - Reversing Hash Functions + +Grover's algorithm could accelerate preimage attacks on hashes +like SHA-256, used for proof-of-work and address generation, but +this is the least concerning threat. Many post-quantum +cryptographic schemes incorporate hash-based constructions as +hashes are considered secure-enough with a large enough digest. + +### Scaling Challenges in Post-Quantum Cryptography + +While post-quantum cryptography (PQC) offers essential +protections against quantum threats, it introduces significant +scaling hurdles due to the inherent design of these algorithms. +Unlike elliptic curve schemes, which rely on compact mathematical +structures, PQC primitives require larger parameters to maintain +security against both classical and quantum adversaries. This +results in substantially bigger public keys, private keys, and +signatures, often by orders of magnitude. The following table +illustrates typical sizes for ML-DSA at a 128-bit post-quantum +security level compared to classical counterparts like 256-bit +ECDSA: + + + +Sizes at 128-bit post-quantum security level. Source: Open +Quantum Safe Project + +As shown, ML-DSA signatures can be over 70 times larger than +ECDSA equivalents, and public keys more than 80 times larger. +Other PQC families exacerbate this: hash-based schemes like +SPHINCS+ may produce signatures up to 41 KB, while even size- +optimized lattice variants like FALCON still exceed classical sizes +by a significant multiple. + +In blockchain contexts, these inflated sizes compound into +systemic scaling issues. Larger signatures bloat individual +transactions, reducing transactions per second (TPS) as blocks fill +faster and require more time for validation. This also strains peer- +to-peer (P2P) communication, increasing bandwidth demands and +propagation delays, which can heighten the risk of network forks or +orphaned blocks in consensus mechanisms like proof-of-work. +Storage requirements are also affected, leading to higher node +operating costs and barriers for participation, especially for +resource-constrained users or validators. + + + These scaling challenges will have to be addressed by all blockchains in the + future. Bitcoin, for example, will have much less than 1 TPS if the max block + size is not increased. + + + + +### The Coordination Problem + +Bitcoin's conservative culture resists protocol changes. Any PQC +upgrade would require consensus on contentious issues such as +migration timelines, potential coin seizure, and block size +increases. Even if the community agreed, every individual user +would need to migrate their coins to new quantum-secure +addresses. Migration requires action from every crypto holder, +many of whom have lost access to their wallets or remain unaware +of the threat. + +These issues exist for every public blockchain, but are uniquely +challenging to Bitcoin due to its lack of clear leadership and +philosophy of technical ossification. + +### The Lost Coin Problem + +An estimated $250 billion to $500 billion worth of Bitcoin is +permanently inaccessible due to lost keys, deceased holders, or +forgotten wallets. [3] These coins cannot be migrated and serve +as a public bounty for creating a cryptographically relevant +quantum computer (CRQC). Quantum attackers will derive private +keys from exposed unmigrated public keys and likely dump billions +of dollars of BTC onto the market. + +> the only technical solution requires a hard +> deadline that freezes unmigrated coins — a +> political impossibility. + +Without such a deadline, the outcome will be that unmigrated +coins are stolen and sold, crashing the market and destroying +confidence in the network. + +### The Migration Timeline Problem + +Post-quantum signatures are 20x–80x larger than current Bitcoin +signatures. Without fundamental architectural changes, Bitcoin's +throughput will collapse to a fraction of its already limited capacity. + +Assuming Bitcoin solves the political and technical challenges, the +migration itself would take months or years. Every holder must +submit at least one transaction to move funds to a quantum-secure +address. Many will send test transactions first. With bloated PQC +signatures choking throughput, the network faces a backlog lasting +months or years while quantum-vulnerable coins remain exposed. + + + These compounding challenges make retrofitting quantum security onto existing + chains extraordinarily difficult. Quantus Network sidesteps this by building + quantum security into the chain from day one. + + + + +### Foundation + +Quantus Network is built on Substrate, a blockchain SDK +developed by Parity Technologies, the team behind Ethereum and +Polkadot. Substrate is highly modular, enabling easy replacement +of components so we can focus on what makes Quantus unique. + +Quantus upgrades Substrate by: + +- Adding support for post-quantum signature schemes +- Upgrading the p2p networking security to be post-quantum +- Adding user-controlled transaction reversibility +- Making the database zk-friendly by aligning all data types to + field-element boundaries + +### Post-Quantum Cryptographic Primitives + +Quantus Network employs NIST-standardized PQC to ensure the +security of transactions and network communications against +quantum threats. At the core of transaction integrity is **ML-DSA** +(Module-Lattice-based Digital Signature Algorithm, formerly known +as CRYSTALS-Dilithium), a lattice-based signature scheme +selected for its balance of security, efficiency, and ease of +implementation. ML-DSA leverages the hardness of problems like +Learning With Errors (LWE) and Short Integer Solution (SIS) over +module lattices, providing robust resistance to both classical and +quantum attacks, including those from Shor's algorithm. + +For transaction signatures, Quantus integrates **ML-DSA-87**, the +parameter set offering the highest security level (NIST Security +Level 5, equivalent to 256-bit classical and 128-bit quantum +security) to protect against potential cryptanalytic breakthroughs +in lattice problems. This choice prioritizes caution, as lattice +cryptography is relatively new and less battle-tested than classical +schemes. The larger parameters mitigate risks from potential +advances in lattice cryptanalysis, which would still leave smaller +key sizes as softer targets. + +#### Alternatives Considered + +ML-DSA was selected over alternatives like FN-DSA (Falcon) due to +FN-DSA's greater implementation complexity (e.g., requiring +floating-point operations, which are blockchain-unfriendly), lack of +deterministic key generation in its specification, and its non- +finalized status at the time of development. + +Hash-based options like SLH-DSA were not chosen because of +their even larger signature sizes (exceeding 17 KB). Crypto-agility +(being able to swap in different signature schemes) is built into +Substrate, so it is relatively easy to add these alternatives at a +future date, should circumstances demand. + +While ML-DSA-87 results in larger keys and signatures, these are +manageable in Quantus's early-stage network, where storage is not +yet a bottleneck, and optimizations like wormhole addresses via +zero-knowledge proofs will address scaling. + +For technical details about the implementation see [QIP-0006](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0006.md). + +### LibP2P - Quantum-Secure Networking + +Quantus Network secures peer-to-peer (P2P) node +communications using a combination of ML-DSA for authentication +and **ML-KEM** (Module-Lattice-based Key Encapsulation +Mechanism, formerly CRYSTALS-Kyber) for encryption. This +integration extends PQC to the libp2p networking stack, modifying +core components for quantum resistance: using ML-DSA-87 +signatures for peer identity and ML-KEM-768 for transport security +(extending the Noise handshake with an additional KEM message +for quantum-resistant shared secrets). + +The P2P layer is often neglected in quantum-security analysis. +Authentication of peers is important, but the worst an attacker +could do at the peer level is impersonate a node and send invalid +messages, which could result in denial-of-service. This attack is +already mitigated by the fact that nodes are generally untrusted in +the blockchain model and nodes can easily switch their keys if the +attack is detected. Likewise, decrypting P2P communications +yields limited attacker benefits (e.g., tracking transaction paths, +mitigated by proxies or Tor), and most data becomes public on- +chain anyway. + +Nevertheless, quantum-securing the P2P layer protects against +eavesdropping, man-in-the-middle attacks, and quantum +decryption, ensuring that node gossip, block propagation, and +other network interactions remain confidential and tamper-proof +for the foreseeable future. + +For technical details about the implementation see [QIP-0004](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0004.md). + +### Scaling PQC - wormhole addresses + +To address the scaling challenges inherent in post-quantum +cryptography, Quantus Network introduces an innovative +aggregated post-quantum signature scheme called **"Wormhole Addresses"**. +This system leverages zero-knowledge proofs (ZKPs) +generated via the Plonky2 proving system (basically STARKs) to +move balance verification off-chain, allowing the chain to verify a +single compact proof without processing individual signatures. +Wormhole Addresses enable the verification of a large number of +transactions with one proof, with the public inputs (e.g., nullifiers, +storage root, exit addresses, and amounts) becoming the primary +limiting factor. This reduces the amortized per-transaction storage +demands to approximately 256 additional bytes per transaction, +much smaller than any known PQC signature scheme. + +The quantum security of the scheme derives from the use of the +secure hash function **Poseidon2** for commitments via FRI (Fast +Reed-Solomon Interactive Oracle Proofs), instead of the quantum- +vulnerable elliptic-curve pairings commonly used in SNARKs. + +Additionally the authentication secrets are hidden behind +Poseidon2. Since secure hash functions are only quadratically +weakened by Grover's algorithm, not broken, hash preimage proofs +can serve as lightweight post-quantum signatures in ZK contexts, +similar to hash-based schemes like SPHINCS+. + +#### Client / Prover Flow + +Users generate a provably unspendable address by double-hashing a salt +concatenated with a secret: + +``` +H(H(salt|secret)) +``` + +This construction prevents false positives (e.g., mistaking a single- +hash public key for an unspendable address) because in Substrate +(and generally) blockchain addresses are the single hash of a +public key, which is derived from the private key via some algebraic +operation, not via a secure hash. The security of the construction +therefore reduces to finding the preimage-of-a-preimage of a +secure hash. Tokens sent to this address are effectively burned. +They cannot be spent because no private key exists for the address +that received them. These coins can therefore be re-minted +without inflating supply. + +For each transfer, a TransferProof storage object is created, +containing details like a unique global transfer count. The user's +wallet generates a Merkle-Patricia-Trie (MPT) storage proof from a +recent block header's storage root to the leaf for this TransferProof. +A nullifier is computed to prevent double-spends: + +``` +H(H(salt | secret | global_transfer_count)) +``` + +#### Aggregator Flow + +Any party (client, miner, or third-party) can aggregate multiple +proofs using Plonky2's recursion, forming a tree of proofs where +each parent proof is a verification of the child proofs, with the child +proofs' public inputs aggregated: + +- Nullifiers pass unchanged +- Exit addresses are deduplicated +- Block hashes are proven to be linked and then all but the most recent is dropped +- Amounts for duplicate exit addresses are summed + +#### Chain / Verifier Flow + +The network verifies the aggregated proof by checking: block hash +is on chain and recent, nullifier uniqueness (to prevent double- +spends), and proof validity. The ZK circuit enforces storage proof +correctness, nullifier computation accuracy, address +unspendability, balance match between inputs and outputs, and +block header linkage. + +#### Why Plonky2 + +- Already audited +- Post-quantum +- No trusted setup +- Efficient proving/verification +- Seamless proof aggregation +- Rust-native implementation +- Compatible with Substrate’s no-std environment + + + Recursive proofs complete in 170 milliseconds with compact sizes (100 KB per + aggregated proof). In an optimal case with 5 MB blocks and all transactions + going to the same output, Wormhole Addresses could pack ~153,000 transactions + into a single block (4.9 MB / 32 bytes per nullifier) — a 223x improvement + over ~685 raw ML-DSA transactions (5 MB / 7.3 KB each). + + +#### Security Notes + +Potential risks include inflation bugs from faulty circuit/verification +implementations, although this would be economically detectable +if re-minted coins exceed balances of zero-send addresses. Users +can optionally prove an address is a wormhole by publishing the +first hash without revealing the secret. Verification transactions are +unsigned, so denial-of-service via failed transactions needs to be +mitigated non-financially. Token supply calculations are +maintained, as re-mints appear as new coins but maintain +maximum supply guarantees via burns. + +For more technical details about the implementation see [QIP-0005](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0005.md). + +### Consensus Mechanism + +Quantus Network uses a Proof-of-Work (PoW) consensus algorithm +that preserves the desirable properties of Bitcoin's consensus +algorithm while improving compatibility with ZK-proof systems by +switching out SHA-256 with **Poseidon2**. + +Importantly, this change is not being made for quantum security. +Cryptographic hash functions like SHA-256 are weakened but not +destroyed by quantum algorithms, notably Grover's. Some post- +quantum signature schemes use secure hashes as a building block +for this reason. + +Poseidon2 is a refinement of the Poseidon hash function. Creating +SNARKs or STARKs for computations involving traditional hash +functions like SHA-256 often requires nearly 100x the number of +gates compared to using Poseidon, which relies entirely on +algebraic functions over field elements, instead of bit-level +operations. + +We use the **Goldilocks field** for both Poseidon2 and Plonky2. The +Goldilocks field's order fits in an unsigned 64-bit integer, which +increases efficiency without compromising soundness. + + + +There are many risks in managing cryptocurrency keys. Most of +them are avoidable. + +### Reversible Transactions + +Quantus Network offers user-configurable reversible transactions. +Senders set a time window during which they can cancel outgoing +transfers. This deters theft and corrects errors without sacrificing +finality. The system uses a modified Substrate "scheduler pallet" +with timestamps. Wallets display countdowns for both sender +(with a cancel button) and recipient. + +Reversible transactions enable novel security protocols while +maintaining decentralization through on-chain enforcement. + +For more technical details see [QIP-0009](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0009.md). + +### Check-Phrases + +Quantus Network introduces "check-phrases," a cryptographically- +secure human-readable checksum for blockchain addresses. The +address is hashed to generate a short sequence of memorable +words from the BIP-39 mnemonic list. Check-phrases protect +against typos, tampering, and address poisoning attacks. A 50,000 +iteration key derivation function makes rainbow table attacks +expensive. For large transactions, users should still verify every +character of the address. + +For more technical detail please see [QIP-0008](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0008.md). + +### High-Security Accounts + +Any account can be upgraded to a "high-security account" with +mandatory reversal periods on all outgoing transfers. A designated +**guardian** (hardware wallet, multisig, or trusted third party) can +cancel suspicious transactions during the reversal period, sending +funds to the guardian instead of the sender or receiver. This opt-in +feature is permanent once activated, preventing thieves from +disabling it. + +Guardians can be chained: a high-security account's guardian can +itself be a high-security account with its own guardian. This creates +composable hierarchies where each guardian has superior +permissions to the account it protects. The design gives users time +to detect and respond to unauthorized activity without +compromising finality for legitimate transfers. + +For more technical details see [QIP-0011](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0011.md). + +### Key Recovery + +Many crypto-fortunes have gone to the grave with their owners. +Quantus Network offers a simple way to specify a recovery address +that can pull your funds at any time, subject to a fixed delay. During +this time, the owner can deny recovery if they have access to the +key. This feature enables survivorship: users have an on-chain will +without the need for courts or estates. + +### HD-Lattice + +Hierarchical Deterministic (HD) wallets are the industry standard +for blockchains, allowing users to back up one seed phrase for all +keys, improving security and convenience over manual backups per +action. Adapting this to lattice schemes like Dilithium involves two +challenges: + +- HMAC-SHA512 outputs can't directly form lattice private keys, + which are polynomials sampled from a ring with certain + properties. +- Non-hardened key derivation relies on elliptic curve addition, + absent in lattices (public keys aren't closed under any algebraic + operation). + +Quantus Network addresses the first issue by using the output of +the HMAC as entropy to deterministically construct the private key, +not as the private key itself. The second issue is less critical and +remains an open research question whether lattice cryptography +can be adapted to address it. + +For more technical details see [QIP-0002](https://github.com/Quantus-Network/improvement-proposals/tree/main/qip-0002). + + + +Quantus Network exists in a changing environment, and we cannot +assume that we will get everything right on the first try. For this +reason, we choose a simple starting point and allow the +governance system to make changes as new information is +acquired. This design makes the blockchain a living entity that can +adapt to its environment at will. In particular, the Substrate +governance process allows deep changes to the chain with minimal +coordination among the various node-runners. + +### Block Rewards + +Quantus Network employs a straightforward tokenomics model imitating that of +Bitcoin. There is a maximum supply of **21,000,000 coins** and a simple heuristic +determines the reward each block: + +``` +block_reward = (max_supply - current_supply) / constant +``` + +This heuristic forms a smooth exponentially decaying curve as the +block_reward contributes to the current_supply which reduces the +block_reward computed at the next block. Any burns from fees or +otherwise reduce current_supply and essentially become part of +the budget for block rewards. The constant is chosen so that, in the +absence of any burns, 99% of the coins will be emitted in about 30 +years. + +### Investor Allocation + +Quantus Network was built with the help of investors who took +great risk in funding it. Private investors are subject to a 4 year +vesting schedule, like the team. Public sale investors will be fully +liquid on day one. The funds raised in the public sale will be +matched with tokens and used for liquidity (DEX, CEX, and market +makers). These investor allocations as well as the liquidity will be +the only "pre-mine". All other tokens will have to be mined into +existence. + +In the event that less than the maximum 10% is sold during the +public sale, there will be a corresponding reduction in the liquidity +tokens and the remainder will be emitted to miners via block +rewards. + +### Company Allocation + +To compensate the team for taking the risk to build new technology +with no promise of success, a portion of the block reward is sent to +the company for approximately four years. This gives a de facto +vesting schedule of about **15% of the total supply** to the company. + +After that point, the company's portion of block rewards can be +turned off, adjusted or redirected according to a token holder vote. + +### Transaction Fees + + + +### Forkless Upgrades + +Quantus Network supports "forkless" upgrades through +Substrate's runtime upgrades, allowing the blockchain's core logic +(the "runtime") to evolve without hard forks that could disrupt the +network or split the community. This is achieved via on-chain +governance referenda, where approved proposals trigger a runtime +swap — essentially replacing the existing WASM code blob with a +new one in a single block, ensuring continuity of state and +operations. This upgrade path minimizes downtime and risks, +empowering the community to iteratively refine the protocol as +real-world usage reveals potential improvements. + +As the community gains confidence in the system over time, the +power to change the runtime will be significantly reduced to limit +the attack surface, should a malicious actor obtain control of the +upgrade process. + +### Governance System + +Quantus Network inherits its governance framework from +Polkadot's OpenGov system via Substrate. Token holders +participate via **conviction voting**, where they agree to lock their +assets for varying periods to amplify their vote's weight. This +amplification can range from 1x (no lock) to 6x (maximum lockup). +This design encourages long-term alignment by tying influence to +commitment. + +Proposals are categorized into multiple voting tracks called +"origins". Each origin has tailored parameters like approval +thresholds (e.g., supermajority for high-impact changes), minimum +deposits to deter spam, preparation/enactment periods, and +decision timelines to prevent gridlock. This multi-track design +allows parallel processing of diverse referenda, from routine +treasury spends to critical runtime upgrades. + +The **Technical Collective** is a curated group of technical experts +serving as a specialized body to propose, review, or whitelist urgent +technical matters, expediting them through a dedicated track while +maintaining community oversight. + +Quantus adopts this system without modifications but starts with a +minimalistic setup to avoid complexity in its early stages. Initially, +only the Technical Collective track is active, which will be used for +binding, high-privilege decisions like protocol upgrades or +parameter tweaks. + +Later, Quantus can add a non-binding community vote track for +gauging sentiment on non-enforceable topics, such as feature +suggestions or ecosystem polls. This system will become binding +when the company turns the network over to the DAO. This phased +approach allows the network to evolve organically via future +governance votes without burdening users with unnecessary +complexity at the beginning. + + + +The current roadmap through 2026, subject to change. + + + + + + + + + + + + + + + +
    + + + +Building Quantus Network comes with inherent risks. + +### Implementation Issues + +Flaws in software logic can cause serious failures in even the best +designed systems. + +### NIST Algorithm Selection Issues + +Potential flaws or backdoors in selected post-quantum standards +(e.g., ML-DSA, ML-KEM) that could emerge post-standardization. In +the worst case, such flaws would allow an attacker to forge +signatures by deriving a private key from the public, representing a +catastrophic failure mode of the chain. If such flaws were made +public, Quantus Network could be upgraded to a new algorithm, +but if such flaws are exploited sparingly they may never be +discovered. + +### Quantum Computing Timelines + +Quantum breakthroughs might arrive much later than anticipated, +delaying the need for PQC; conversely, secretive development (e.g. +by governments) could lead to sudden threats if the blockchain +community fails to update swiftly. + +### Other Considerations + +General adoption barriers, regulatory uncertainties in +finance/blockchain, and the inherent volatility of crypto +ecosystems. + + + +
    + + + Shor, P. W. (1997). Polynomial-time algorithms for prime factorization and + discrete logarithms on a quantum computer. _SIAM Journal on Computing_, 26(5), + 1484–1509. https://doi.org/10.1137/S0097539795293172 + + + + Grover, L.K. (1996). A fast quantum mechanical algorithm for database search. + _Proceedings of the Twenty-Eight Annual ACM Symposium on Theory of Computing_, + 212-219. https://doi.org/10.1145/237814.237866 + + + + Chainalysis. (2024). _The Chainalysis 2024 Crypto Crime Report_. + https://www.chainalysis.com/blog/2024-crypto-crime-report-introduction/ + + + + National Institute of Standards and Technology. (2024). _FIPS 204: + Module-Lattice-Based Digital Signature Standard (ML- DSA)_. U.S. Department of + Commerce. https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf + + + + National Institute of Standards and Technology. (2024). _FIPS 203: + Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)_. U.S. + Department of Commerce. + https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf + + + + Häner, T., Jaques, S., Naehrig, M., Roetteler, M., & Soeken, M. (2020). + Improved quantum circuits for elliptic curve discrete logarithms. + _arXiv:2002.12480_. https://arxiv.org/abs/2002.12480 + + + + Gidney, C., & Ekerå, M. (2021). _How to factor 2048 bit RSA integers in 8 + hours using 20 million noisy qubits_. _arXiv:1905.09749_. + https://arxiv.org/abs/1905.09749 + + + + Aggarwal, D., et al. (2021). Assessment of Quantum Threat To Bitcoin and + Derived Cryptocurrencies. _ePrint IACR_. https://eprint.iacr.org/2021/967.pdf + + + + Roetteler, M., Naehrig, M., Svore, K. M., & Lauter, K. (2017). Quantum + resource estimates for computing elliptic curve discrete logarithms. + _arXiv:1706.06752_. https://arxiv.org/abs/1706.06752 + + + + Open Quantum Safe Project. (n.d.). ML-DSA | Open Quantum Safe. Retrieved + January 29, 2026, from + https://openquantumsafe.org/liboqs/algorithms/sig/ml-dsa.html + diff --git a/website/src/contents/whitepapers/es-ES/v0.3.3.mdx b/website/src/contents/whitepapers/es-ES/v0.3.3.mdx new file mode 100644 index 0000000..f1cdd30 --- /dev/null +++ b/website/src/contents/whitepapers/es-ES/v0.3.3.mdx @@ -0,0 +1,850 @@ +--- +title: "Quantus Network Whitepaper" +version: "0.3.3" +publishedDate: "2026-03-21" +updatedDate: "2026-03-21" +authors: ["Christopher Smith"] +changelog: + - "Revisión amplia: aviso legal, índice, capítulos numerados (01–09), portada PDF, TOC; «References & Further Reading» sustituye el cierre." + - "Nuevo capítulo: La crisis de migración (coordinación, monedas perdidas, plazos de migración PQC)." + - "Introducción y sección de amenaza cuántica reescritas: marco CRQC, cuatro categorías de amenaza numeradas, citas en línea." + - "Arquitectura y secciones técnicas ampliadas o aclaradas (Foundation/Substrate, LibP2P, wormhole/Plonky2, consenso/campo Goldilocks)." + - "Hoja de ruta: Bell Mainnet Q2 2026; Fermi Upgrade Q4 2026; Planck Beta añade integración ZK." +pdfCover: true +# Astro `render().headings` omite los `

    ` en JSX y ChapterHeading; los slugs de ancla coinciden con los id de `###` en Markdown. +toc: + insertBefore: + la-amenaza-cuántica: + - slug: legal-disclaimer + text: Aviso legal + - slug: contents + text: Contenido + - slug: chapter-01 + text: Introducción + fundamentos-de-la-computación-cuántica: + - slug: chapter-02 + text: La amenaza cuántica para la blockchain + el-problema-de-coordinación: + - slug: chapter-03 + text: La crisis de la migración + fundamentos: + - slug: chapter-04 + text: Arquitectura de Quantus Network + transacciones-reversibles: + - slug: chapter-05 + text: Preservación del patrimonio + recompensas-de-bloque: + - slug: chapter-06 + text: Tokenómica y gobernanza + problemas-de-implementación: + - slug: chapter-07 + text: Hoja de ruta + - slug: chapter-08 + text: Riesgos + insertAfter: + otras-consideraciones: + - slug: chapter-09 + text: Referencias y lecturas adicionales +--- + +import CalloutV2 from "@/components/features/whitepaper/mdx/CalloutV2.astro"; +import Figure from "@/components/features/whitepaper/mdx/Figure.astro"; +import Grid from "@/components/features/whitepaper/mdx/Grid.astro"; +import Column from "@/components/features/whitepaper/mdx/Column.astro"; +import TimelineV2 from "@/components/features/whitepaper/mdx/TimelineV2.astro"; +import ResponsiveTableV2 from "@/components/features/whitepaper/mdx/ResponsiveTableV2.astro"; +import SiteSocials from "@/components/ui/SiteSocials.astro"; +import OrderedList from "@/components/features/whitepaper/mdx/OrderedList.astro"; +import Divider from "@/components/features/whitepaper/mdx/Divider.astro"; +import ChapterHeading from "@/components/features/whitepaper/mdx/ChapterHeading.astro"; +import Reference from "@/components/features/whitepaper/mdx/Reference.astro"; +import ReferenceMarker from "@/components/features/whitepaper/mdx/ReferenceMarker.astro"; + +

    + +_Este whitepaper se ofrece únicamente con fines informativos y +no constituye una oferta de venta, una solicitud de oferta de compra +ni una recomendación sobre ningún valor, inversión o producto +financiero. Los lectores deben realizar su propia diligencia debida y +consultar a profesionales cualificados antes de tomar decisiones de inversión. +Quantus Network no ofrece declaraciones ni garantías +sobre la exactitud o integridad de la información aquí contenida._ + +

    + Contenido +

    + + + +
    + + + +### La amenaza cuántica + +Las blockchains tradicionales enfrentan una amenaza existencial por los +ordenadores cuánticos criptográficamente relevantes (CRQC). Los fundamentos +criptográficos de las blockchains dependen de la dificultad del +problema del logaritmo discreto (DLP), y los algoritmos cuánticos, +en particular el de Shor, pueden resolver el DLP exponencialmente más rápido que +los ordenadores clásicos. Esta vulnerabilidad podría permitir a adversarios +cuánticos derivar claves privadas a partir de claves públicas, lo que les +permitiría falsificar transacciones y descifrar datos financieros +sensibles. + +> sin actualizaciones proactivas resistentes a la computación cuántica, la economía cripto de billones de dólares +> arriesga una desvalorización repentina por tales ataques. + +### Propuesta de valor única + +Nombrada por la palabra latina que significa «cuánto», Quantus Network +permite dinero privado escalable y seguro en el sentido cuántico. Quantus no es una +plataforma general de contratos inteligentes. Como un restaurante con unos pocos +platos muy perfeccionados, Quantus ofrece: + +- Firmas post-cuánticas para todas las transacciones +- Firmas y cifrado post-cuánticos (ML-DSA y ML-KEM) para asegurar conexiones entre pares +- Pruebas de conocimiento cero post-cuánticas para escalar +- Cuentas de alta seguridad para disuadir el robo y permitir recuperación de errores +- Frases de comprobación legibles para verificación sencilla de direcciones + +La decisión de centrarse en dinero privado escalable y seguro en el sentido cuántico +surge de la amenaza que los CRQC plantean al sector y de la incapacidad de Bitcoin +para abordar estos retos. + + + +### Fundamentos de la computación cuántica + +Los ordenadores cuánticos aprovechan principios como la superposición y el +entrelazamiento para realizar cálculos intratables para +máquinas clásicas. A diferencia de los bits clásicos, que son 0 o 1, +los qubits pueden existir en múltiples estados a la vez, +permitiendo paralelismo exponencial para ciertos problemas. Esta +capacidad plantea riesgos existenciales para los sistemas criptográficos que sustentan +las finanzas en blockchain, ya que los algoritmos desarrollados para +hardware cuántico socavan los supuestos de seguridad de la mayor parte de la +criptografía de clave pública. + +**El algoritmo de Shor**, presentado en 1994 por Peter Shor, ofrece un +método en tiempo polinómico para factorizar enteros grandes y resolver el +problema del logaritmo discreto en un ordenador cuántico. Explota las +transformadas cuánticas de Fourier (QFT) para hallar el periodo de una función, +permitiendo invertir eficientemente las funciones trampilla que sustentan +esquemas como RSA o la criptografía de curvas elípticas (ECC). Para las +finanzas en blockchain, esto significa que un atacante con un ordenador cuántico suficientemente +potente (estimado en ~2.000 qubits lógicos ) +podría derivar claves privadas a partir de claves públicas en tiempo polinómico O(n³): una aceleración extrema +que deja obsoletos los sistemas vulnerables de la noche a la mañana. + +**El algoritmo de Grover**, propuesto por Lov Grover en 1996, ofrece una +aceleración cuadrática para búsquedas no estructuradas, reduciendo el +tiempo de búsqueda de O(n) a O(√n) operaciones. Aunque no es tan +devastador como Shor para la criptografía asimétrica, Grover +afecta primitivas simétricas como funciones hash y el cifrado AES, +reduciendo efectivamente a la mitad el nivel de seguridad (p. ej., una clave de 256 bits +se comporta como 128 bits frente a ataques cuánticos). Este ataque se +mitiga duplicando los bits de seguridad en lugar de cambiar el +esquema criptográfico. Además, la aceleración cuadrática de Grover es poco práctica por sus altos requisitos de qubits y puertas, +exigiendo miles de millones de operaciones secuenciales con paralelización limitada, +lo que la hace inviable para inversiones en el mundo real incluso con +hardware futuro. + +### Cuatro categorías de amenaza + +#### 01 - Falsificar firmas digitales + +El algoritmo de Shor amenaza directamente las firmas basadas en ECC usadas en +la mayoría de las blockchains (p. ej., la curva secp256k1 de Bitcoin), permitiendo a +adversarios suplantar usuarios y autorizar transacciones +fraudulentas. Tal capacidad supondría un fallo crítico de +la característica más básica de una blockchain. + +#### 02 - Falsificar pruebas falsas en sistemas de conocimiento cero + +Muchas pruebas de conocimiento cero, como las de zk-SNARKs para +finanzas centradas en la privacidad, dependen de la dificultad del logaritmo discreto mediante +emparejamientos de curvas elípticas para los compromisos. Shor podría permitir +crear pruebas inválidas que parezcan válidas, lo que permitiría a un atacante acuñar monedas nuevas o falsificar el estado de las capas 2 (L2). + +#### 03 - Descifrar información secreta + +Los ataques cuánticos podrían exponer datos cifrados protegidos por +esquemas de clave pública vulnerables en protocolos de privacidad como Zcash +o Monero. También podrían descifrar comunicaciones p2p en protocolos +financieros, revelando detalles patrimoniales sensibles y permitiendo robos +dirigidos. + +#### 04 - Invertir funciones hash + +El algoritmo de Grover podría acelerar ataques de preimagen sobre hashes +como SHA-256, usados en prueba de trabajo y generación de direcciones, pero +es la amenaza menos preocupante. Muchos esquemas +criptográficos post-cuánticos incorporan construcciones basadas en hash, ya que los +hashes se consideran suficientemente seguros con un digest lo bastante grande. + +### Retos de escalado en la criptografía post-cuántica + +Aunque la criptografía post-cuántica (PQC) ofrece protecciones esenciales +frente a amenazas cuánticas, introduce obstáculos de escalado importantes +debido al diseño inherente de estos algoritmos. +A diferencia de los esquemas de curvas elípticas, que se apoyan en estructuras matemáticas compactas, +las primitivas PQC requieren parámetros mayores para mantener la +seguridad frente a adversarios clásicos y cuánticos. Ello +produce claves públicas, claves privadas y firmas notablemente mayores, +a menudo en órdenes de magnitud. La siguiente tabla +ilustra tamaños típicos de ML-DSA a un nivel de seguridad post-cuántica de 128 bits +frente a equivalentes clásicos como ECDSA de 256 bits: + + + +Tamaños a nivel de seguridad post-cuántica de 128 bits. Fuente: Open +Quantum Safe Project + +Como se ve, las firmas ML-DSA pueden ser más de 70 veces mayores que las +equivalentes ECDSA, y las claves públicas más de 80 veces mayores. +Otras familias PQC lo agravan: esquemas basados en hash como +SPHINCS+ pueden producir firmas de hasta 41 KB, mientras que variantes lattice optimizadas en tamaño +como FALCON siguen superando los tamaños clásicos +en un múltiplo significativo. + +En contextos blockchain, estos tamaños inflados se acumulan en +problemas de escalado sistémico. Las firmas mayores hinchan las +transacciones individuales, reduciendo las transacciones por segundo (TPS) al llenarse los bloques +más rápido y requerir más tiempo de validación. También tensan la comunicación peer-to-peer (P2P), aumentando el ancho de banda y los +retrasos de propagación, lo que puede aumentar el riesgo de bifurcaciones u +bloques huérfanos en mecanismos de consenso como la prueba de trabajo. +Los requisitos de almacenamiento también se ven afectados, con mayores costes operativos de los nodos y barreras a la participación, especialmente para +usuarios o validadores con recursos limitados. + + + Estos retos de escalado tendrán que abordarlos todas las blockchains en el + futuro. Bitcoin, por ejemplo, tendrá mucho menos de 1 TPS si no se aumenta el + tamaño máximo del bloque. + + + + +### El problema de coordinación + +La cultura conservadora de Bitcoin resiste los cambios de protocolo. Cualquier mejora PQC +exigiría consenso sobre cuestiones polémicas como plazos de migración, +posible decomiso de monedas y aumentos del tamaño de bloque. +Incluso si la comunidad acordara, cada usuario +tendría que migrar sus monedas a nuevas direcciones seguras en el sentido cuántico. +La migración exige acción de todos los titulares de cripto, +muchos de los cuales han perdido acceso a sus monederos o ignoran la +amenaza. + +Estos problemas existen en toda blockchain pública, pero son singularmente +difíciles para Bitcoin por su falta de liderazgo claro y su +filosofía de osificación técnica. + +### El problema de las monedas perdidas + +Se estima que entre 250.000 y 500.000 millones de dólares en Bitcoin son +inaccesibles de forma permanente por claves perdidas, titulares fallecidos o +monederos olvidados. [3] Estas monedas no pueden migrarse y actúan +como recompensa pública por crear un ordenador cuántico criptográficamente relevante (CRQC). Los atacantes cuánticos derivarán claves privadas +de claves públicas no migradas y probablemente volcarán miles de millones +de dólares en BTC al mercado. + +> la única solución técnica exige un plazo estricto +> que congele las monedas no migradas: una +> imposibilidad política. + +Sin tal plazo, el resultado será que las monedas no migradas +se roben y vendan, hundiendo el mercado y destruyendo la +confianza en la red. + +### El problema del calendario de migración + +Las firmas post-cuánticas son entre 20 y 80 veces mayores que las firmas actuales de Bitcoin. +Sin cambios arquitectónicos fundamentales, el rendimiento de Bitcoin +colapsará a una fracción de su capacidad ya limitada. + +Suponiendo que Bitcoin resuelve los retos políticos y técnicos, la +migración en sí llevaría meses o años. Cada titular debe +enviar al menos una transacción para mover fondos a una dirección segura en el sentido cuántico. +Muchos enviarán primero transacciones de prueba. Con firmas PQC hinchadas asfixiando el rendimiento, la red enfrenta una cola que dura +meses o años mientras las monedas vulnerables al quantum siguen expuestas. + + + Estos retos acumulados hacen extraordinariamente difícil añadir seguridad + cuántica a cadenas existentes. Quantus Network lo evita integrando la + seguridad cuántica en la cadena desde el primer día. + + + + +### Fundamentos + +Quantus Network está construido sobre Substrate, un SDK de blockchain +desarrollado por Parity Technologies, el equipo detrás de Ethereum y +Polkadot. Substrate es altamente modular, lo que permite sustituir componentes fácilmente para centrarnos en lo que hace único a Quantus. + +Quantus mejora Substrate: + +- Añadiendo soporte para esquemas de firma post-cuánticos +- Actualizando la seguridad de la red p2p a post-cuántica +- Añadiendo reversibilidad de transacciones controlada por el usuario +- Haciendo la base de datos compatible con zk alineando todos los tipos de datos con + límites de elementos de campo + +### Primitivas criptográficas post-cuánticas + +Quantus Network emplea PQC estandarizada por el NIST para garantizar la +seguridad de transacciones y comunicaciones de red frente a +amenazas cuánticas. En el núcleo de la integridad de las transacciones está **ML-DSA** +(Algoritmo de firma digital basado en módulos-retícula, antes conocido como +CRYSTALS-Dilithium), un esquema de firma basado en retículos seleccionado por su equilibrio entre seguridad, eficiencia y facilidad de +implementación. ML-DSA aprovecha la dificultad de problemas como +Learning With Errors (LWE) y Short Integer Solution (SIS) sobre +módulos reticulares, ofreciendo resistencia robusta frente a ataques clásicos y +cuánticos, incluidos los del algoritmo de Shor. + +Para firmas de transacción, Quantus integra **ML-DSA-87**, el conjunto de parámetros +con el nivel de seguridad más alto (Nivel 5 del NIST, +equivalente a 256 bits clásicos y 128 bits cuánticos) +para proteger frente a posibles avances en criptanálisis de retículos. Esta elección prioriza la cautela, ya que la criptografía de retículos es relativamente nueva y menos probada en combate que los esquemas clásicos. +Los parámetros mayores mitigan riesgos de avances potenciales +en criptanálisis de retículos, que aún dejarían tamaños de clave +menores como objetivos más débiles. + +#### Alternativas consideradas + +Se eligió ML-DSA frente a alternativas como FN-DSA (Falcon) por la mayor complejidad de implementación de FN-DSA (p. ej., requiere +operaciones en coma flotante, poco adecuadas a blockchain), la ausencia de +generación de claves determinista en su especificación y su estado no +finalizado en el momento del desarrollo. + +Las opciones basadas en hash como SLH-DSA no se eligieron por sus +firmas aún mayores (más de 17 KB). La cripto-agilidad +(capacidad de intercambiar esquemas de firma) está integrada en +Substrate, por lo que es relativamente sencillo añadir estas alternativas en el +futuro si las circunstancias lo exigen. + +Aunque ML-DSA-87 produce claves y firmas mayores, son +gestionables en la red en fase inicial de Quantus, donde el almacenamiento aún no +es un cuello de botella, y optimizaciones como direcciones wormhole mediante +pruebas de conocimiento cero abordarán el escalado. + +Para detalles técnicos de la implementación véase [QIP-0006](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0006.md). + +### LibP2P - Red segura en el sentido cuántico + +Quantus Network asegura las comunicaciones entre nodos peer-to-peer (P2P) +combinando ML-DSA para autenticación +y **ML-KEM** (Mecanismo de encapsulación de claves basado en módulos-retícula, +antes CRYSTALS-Kyber) para cifrado. Esta integración extiende el PQC a la pila libp2p, modificando +componentes centrales para resistencia cuántica: firmas ML-DSA-87 +para identidad de pares y ML-KEM-768 para seguridad de transporte +(extendiendo el handshake Noise con un mensaje KEM adicional +para secretos compartidos resistentes al quantum). + +La capa P2P suele descuidarse en el análisis de seguridad cuántica. +La autenticación de pares importa, pero lo peor que un atacante +puede hacer a nivel de pares es suplantar un nodo y enviar mensajes +inválidos, lo que podría causar denegación de servicio. Este ataque ya se +mitiga porque los nodos no suelen ser de confianza en el +modelo blockchain y pueden cambiar de clave fácilmente si se detecta el +ataque. Asimismo, descifrar comunicaciones P2P +ofrece beneficios limitados al atacante (p. ej., rastrear rutas de transacción, +mitigado con proxies o Tor), y la mayoría de los datos acaban siendo públicos en +cadena. + +No obstante, asegurar la capa P2P en el sentido cuántico protege frente a +escuchas, ataques intermediarios y descifrado +cuántico, garantizando que el gossip de nodos, la propagación de bloques y +otras interacciones de red sigan siendo confidenciales e íntegras +en el futuro previsible. + +Para detalles técnicos véase [QIP-0004](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0004.md). + +### Escalado PQC - direcciones wormhole + +Para abordar los retos de escalado inherentes a la criptografía +post-cuántica, Quantus Network introduce un esquema agregado innovador de firma post-cuántica llamado **«Wormhole Addresses»**. +Este sistema aprovecha pruebas de conocimiento cero (ZKP) +generadas con el sistema de pruebas Plonky2 (básicamente STARKs) para +llevar la verificación de saldos fuera de la cadena, permitiendo que la cadena verifique +una única prueba compacta sin procesar firmas individuales. +Las Wormhole Addresses permiten verificar un gran número de +transacciones con una prueba, siendo los inputs públicos (p. ej., nullifiers, +raíz de almacenamiento, direcciones de salida e importes) el principal +factor limitador. Esto reduce las necesidades de almacenamiento amortizadas por transacción +a unos 256 bytes adicionales por transacción, +mucho menor que cualquier esquema de firma PQC conocido. + +La seguridad cuántica del esquema proviene del uso de la función hash segura +**Poseidon2** para compromisos mediante FRI (Fast +Reed-Solomon Interactive Oracle Proofs), en lugar de los emparejamientos de curvas elípticas +vulnerables al quantum habituales en SNARKs. + +Además, los secretos de autenticación quedan ocultos tras +Poseidon2. Como las funciones hash seguras solo se debilitan cuadráticamente +con el algoritmo de Grover, no se rompen; las pruebas de preimagen hash +pueden servir como firmas post-cuánticas ligeras en contextos ZK, +similares a esquemas basados en hash como SPHINCS+. + +#### Flujo cliente / probador + +Los usuarios generan una dirección demostrablemente no gastable doble-hasheando una sal +concatenada con un secreto: + +``` +H(H(salt|secret)) +``` + +Esta construcción evita falsos positivos (p. ej., confundir una clave pública de hash simple +con una dirección no gastable) porque en Substrate +(y en general) las direcciones blockchain son el hash simple de una +clave pública derivada de la clave privada mediante alguna operación algebraica, +no mediante un hash seguro. La seguridad de la construcción +se reduce por tanto a hallar la preimagen-de-preimagen de un +hash seguro. Los tokens enviados a esta dirección se queman de facto. +No pueden gastarse porque no existe clave privada para la dirección +que los recibió. Estas monedas pueden acuñarse de nuevo +sin inflar el suministro. + +Para cada transferencia se crea un objeto de almacenamiento TransferProof, +con detalles como un recuento global de transferencias único. El monedero del usuario +genera una prueba de almacenamiento Merkle-Patricia-Trie (MPT) desde la +raíz de almacenamiento de una cabecera de bloque reciente hasta la hoja de este TransferProof. +Se calcula un nullifier para evitar doble gasto: + +``` +H(H(salt | secret | global_transfer_count)) +``` + +#### Flujo del agregador + +Cualquier parte (cliente, minero o tercero) puede agregar múltiples +pruebas mediante la recursión de Plonky2, formando un árbol de pruebas donde +cada prueba padre verifica las hijas, agregando los inputs públicos hijos: + +- Los nullifiers pasan sin cambios +- Las direcciones de salida se deduplican +- Los hashes de bloque se prueban enlazados y luego se descartan salvo el más reciente +- Los importes para direcciones de salida duplicadas se suman + +#### Flujo cadena / verificador + +La red verifica la prueba agregada comprobando: el hash de bloque +está en cadena y es reciente, unicidad del nullifier (para evitar doble +gasto) y validez de la prueba. El circuito ZK impone corrección de la prueba de almacenamiento, +precisión del nullifier, no gastabilidad de la dirección, +coincidencia de saldos entre entradas y salidas y +enlace de cabeceras de bloque. + +#### Por qué Plonky2 + +- Ya auditado +- Post-cuántico +- Sin trusted setup +- Prueba/verificación eficientes +- Agregación de pruebas fluida +- Implementación nativa en Rust +- Compatible con el entorno no-std de Substrate + + + Las pruebas recursivas terminan en 170 milisegundos con tamaños compactos (100 + KB por prueba agregada). En un caso óptimo con bloques de 5 MB y todas las + transacciones hacia la misma salida, las Wormhole Addresses podrían empaquetar + ~153.000 transacciones en un solo bloque (4,9 MB / 32 bytes por nullifier): + una mejora de 223x frente a ~685 transacciones ML-DSA en bruto (5 MB / 7,3 KB + cada una). + + +#### Notas de seguridad + +Los riesgos potenciales incluyen errores de inflación por implementaciones defectuosas de circuito/verificación, +aunque serían detectables económicamente si +las monedas reacuñadas superan los saldos de direcciones de envío cero. Los usuarios +pueden opcionalmente probar que una dirección es wormhole publicando el +primer hash sin revelar el secreto. Las transacciones de verificación no están +firmadas, por lo que la denegación de servicio por transacciones fallidas debe +mitigarse sin medios financieros. Los cálculos de suministro de tokens se +mantienen, ya que las reacuñaciones aparecen como monedas nuevas pero conservan +garantías de suministro máximo mediante quemas. + +Para más detalles técnicos véase [QIP-0005](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0005.md). + +### Mecanismo de consenso + +Quantus Network usa un algoritmo de consenso Proof-of-Work (PoW) +que conserva las propiedades deseables del consenso de Bitcoin +mejorando la compatibilidad con sistemas de prueba ZK sustituyendo +SHA-256 por **Poseidon2**. + +Importante: este cambio no se hace por seguridad cuántica. +Las funciones hash criptográficas como SHA-256 se debilitan pero no se destruyen +con algoritmos cuánticos, en particular Grover. Algunos esquemas de firma +post-cuánticos usan hashes seguros como bloque básico +por esta razón. + +Poseidon2 es un refinamiento de la función hash Poseidon. Crear +SNARKs o STARKs para cómputos con hashes tradicionales +como SHA-256 suele requerir casi 100 veces más +puertas que usando Poseidon, que se apoya por completo en +funciones algebraicas sobre elementos de campo en lugar de operaciones a nivel de bit. + +Usamos el **campo Goldilocks** para Poseidon2 y Plonky2. El orden del +campo Goldilocks cabe en un entero sin signo de 64 bits, lo que +aumenta la eficiencia sin comprometer la solidez. + + + +Hay muchos riesgos al gestionar claves de criptomonedas. La mayoría +se pueden evitar. + +### Transacciones reversibles + +Quantus Network ofrece transacciones reversibles configurables por el usuario. +Los remitentes fijan una ventana temporal en la que pueden cancelar transferencias +salientes. Esto disuade el robo y corrige errores sin sacrificar la +finalidad. El sistema usa un pallet Substrate «scheduler» modificado +con marcas de tiempo. Los monederos muestran cuentas atrás para remitente +(con botón cancelar) y destinatario. + +Las transacciones reversibles permiten protocolos de seguridad novedosos manteniendo la +descentralización mediante aplicación en cadena. + +Para más detalles técnicos véase [QIP-0009](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0009.md). + +### Frases de comprobación + +Quantus Network introduce «check-phrases», una suma de comprobación legible y criptográficamente +segura para direcciones blockchain. La dirección se hashea para generar una secuencia corta de palabras memorables +de la lista mnemónica BIP-39. Las frases de comprobación protegen +frente a erratas, manipulación y ataques de envenenamiento de direcciones. Una función de derivación de clave de 50.000 iteraciones +hace costosos los ataques de tabla arcoíris. Para transacciones grandes, los usuarios deben seguir verificando cada +carácter de la dirección. + +Para más detalle técnico véase [QIP-0008](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0008.md). + +### Cuentas de alta seguridad + +Cualquier cuenta puede mejorarse a «cuenta de alta seguridad» con +periodos de reversión obligatorios en todas las transferencias salientes. Un **guardián** designado +(monedero hardware, multisig o tercero de confianza) puede +cancelar transacciones sospechosas durante el periodo de reversión, enviando +fondos al guardián en lugar del remitente o receptor. Esta función opt-in es permanente una vez activada, impidiendo que los ladrones la desactiven. + +Los guardianes pueden encadenarse: el guardián de una cuenta de alta seguridad puede +ser a su vez una cuenta de alta seguridad con su propio guardián. Esto crea +jerarquías composables donde cada guardián tiene permisos superiores +sobre la cuenta que protege. El diseño da tiempo a los usuarios para detectar y responder a actividad no autorizada sin +comprometer la finalidad de transferencias legítimas. + +Para más detalles técnicos véase [QIP-0011](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0011.md). + +### Recuperación de claves + +Muchas fortunas cripto han ido a la tumba con sus dueños. +Quantus Network ofrece una forma sencilla de especificar una dirección de recuperación +que puede retirar sus fondos en cualquier momento, sujeta a un retraso fijo. Durante +ese tiempo, el propietario puede denegar la recuperación si tiene acceso a la +clave. Esta función permite la supervivencia: los usuarios tienen un testamento en cadena +sin tribunales ni herencias formales. + +### HD-Lattice + +Los monederos jerárquicos deterministas (HD) son el estándar del sector +para blockchains, permitiendo respaldar una sola frase semilla para todas las +claves, mejorando seguridad y comodidad frente a copias manuales por +acción. Adaptar esto a esquemas reticulares como Dilithium plantea dos +retos: + +- Las salidas HMAC-SHA512 no pueden formar directamente claves privadas reticulares, + que son polinomios muestreados de un anillo con ciertas + propiedades. +- La derivación de claves no endurecida se apoya en la suma en curvas elípticas, + ausente en retículos (las claves públicas no son cerradas bajo ninguna operación algebraica). + +Quantus Network aborda el primer punto usando la salida del +HMAC como entropía para construir determinísticamente la clave privada, +no como la clave en sí. El segundo punto es menos crítico y +sigue siendo una pregunta abierta de investigación si la criptografía reticular +puede adaptarse para resolverlo. + +Para más detalles técnicos véase [QIP-0002](https://github.com/Quantus-Network/improvement-proposals/tree/main/qip-0002). + + + +Quantus Network existe en un entorno cambiante y no podemos +asumir que acertaremos a la primera. Por ello elegimos un +punto de partida sencillo y permitimos que el sistema de gobernanza +realice cambios a medida que se obtiene nueva información. Este diseño convierte la blockchain en una entidad viva que puede +adaptarse a su entorno. En particular, el proceso de gobernanza de Substrate +permite cambios profundos en la cadena con coordinación mínima +entre los distintos operadores de nodos. + +### Recompensas de bloque + +Quantus Network emplea un modelo de tokenómica sencillo que imita el de +Bitcoin. Hay un suministro máximo de **21.000.000 monedas** y una heurística simple +determina la recompensa por bloque: + +``` +block_reward = (max_supply - current_supply) / constant +``` + +Esta heurística forma una curva exponencial suavemente decreciente a medida que la +block_reward contribuye al current_supply, lo que reduce la +block_reward calculada en el siguiente bloque. Las quemas por comisiones u +otras reducen el current_supply y pasan a formar parte del +presupuesto de recompensas de bloque. La constante se elige para que, sin +ninguna quema, el 99% de las monedas se emita en unos 30 +años. + +### Asignación a inversores + +Quantus Network se construyó con la ayuda de inversores que asumieron +gran riesgo al financiarlo. Los inversores privados están sujetos a un calendario de adquisición de 4 años, +como el equipo. Los inversores de la venta pública tendrán liquidez total el primer día. Los fondos recaudados en la venta pública se +emparejarán con tokens y se usarán para liquidez (DEX, CEX y market +makers). Estas asignaciones a inversores junto con la liquidez serán +el único «pre-minado». El resto de tokens deberá minarse hasta +existir. + +Si se vende menos del máximo del 10% durante la +venta pública, habrá una reducción proporcional de los tokens de +liquidez y el resto se emitirá a mineros mediante recompensas de bloque. + +### Asignación a la compañía + +Para compensar al equipo por asumir el riesgo de construir tecnología nueva +sin garantía de éxito, una parte de la recompensa de bloque se envía a la +compañía durante unos cuatro años. Esto supone un calendario de adquisición de facto de unos **15% del suministro total** para la compañía. + +Tras ese punto, la parte de la compañía en las recompensas de bloque puede +apagarse, ajustarse o redirigirse según el voto de los titulares de tokens. + +### Comisiones de transacción + + + +### Actualizaciones sin bifurcación + +Quantus Network admite actualizaciones «sin bifurcación» mediante +las actualizaciones de runtime de Substrate, permitiendo que la lógica central de la blockchain +(el «runtime») evolucione sin hard forks que perturben la +red o dividan la comunidad. Se logra mediante referendos de gobernanza en cadena, donde las propuestas aprobadas activan un intercambio de runtime +—sustituyendo esencialmente el blob de código WASM existente por uno +nuevo en un solo bloque, asegurando continuidad de estado y +operaciones. Esta vía minimiza tiempos de inactividad y riesgos, +empoderando a la comunidad para refinar el protocolo de forma iterativa a medida que el uso real revela mejoras. + +A medida que la comunidad gana confianza en el sistema, el +poder de cambiar el runtime se reducirá de forma significativa para limitar la +superficie de ataque si un actor malicioso obtiene el control del +proceso de actualización. + +### Sistema de gobernanza + +Quantus Network hereda su marco de gobernanza del +sistema OpenGov de Polkadot vía Substrate. Los titulares de tokens +participan mediante **voto con convicción**, bloqueando sus +activos durante periodos variables para amplificar el peso del voto. La amplificación puede ir de 1x (sin bloqueo) a 6x (bloqueo máximo). +Este diseño fomenta la alineación a largo plazo vinculando influencia al +compromiso. + +Las propuestas se categorizan en múltiples pistas de votación llamadas +«origins». Cada origin tiene parámetros a medida como umbrales de aprobación +(p. ej., supermayoría para cambios de alto impacto), depósitos mínimos contra spam, periodos de preparación/ejecución y +plazos de decisión para evitar bloqueos. Este diseño multipista +permite procesar en paralelo referendos diversos, desde gastos rutinarios del tesoro +hasta actualizaciones críticas de runtime. + +El **Technical Collective** es un grupo curado de expertos técnicos +que actúa como órgano especializado para proponer, revisar o incluir en lista blanca asuntos técnicos urgentes, +acelerándolos por una pista dedicada manteniendo la supervisión comunitaria. + +Quantus adopta este sistema sin modificaciones pero comienza con una +configuración minimalista para evitar complejidad en las primeras etapas. Inicialmente, +solo está activa la pista del Technical Collective, usada para +decisiones vinculantes de alto privilegio como actualizaciones de protocolo o +ajustes de parámetros. + +Más adelante, Quantus puede añadir una pista de voto comunitario no vinculante para +sondear el sentimiento sobre temas no exigibles, como sugerencias de funciones +o encuestas del ecosistema. Este sistema se volverá vinculante +cuando la compañía entregue la red al DAO. Este enfoque por fases +permite que la red evolucione de forma orgánica mediante futuros votos de gobernanza +sin cargar a los usuarios con complejidad innecesaria al principio. + + + +La hoja de ruta actual hasta 2026, sujeta a cambios. + + + + + + + + + + + + + + + +
    + + + +Construir Quantus Network conlleva riesgos inherentes. + +### Problemas de implementación + +Defectos en la lógica del software pueden causar fallos graves incluso en los sistemas mejor +diseñados. + +### Problemas de selección de algoritmos del NIST + +Defectos o puertas traseras potenciales en estándares post-cuánticos seleccionados +(p. ej., ML-DSA, ML-KEM) que podrían surgir tras la estandarización. En el +peor caso, tales defectos permitirían a un atacante falsificar +firmas derivando la clave privada de la pública, lo que representaría un +modo de fallo catastrófico de la cadena. Si tales defectos se hicieran públicos, Quantus Network podría actualizarse a un nuevo algoritmo, +pero si se explotan de forma escasa quizá nunca se +descubran. + +### Plazos de la computación cuántica + +Los avances cuánticos podrían llegar mucho más tarde de lo previsto, +retrasando la necesidad de PQC; a la inversa, un desarrollo secreto (p. ej. +por gobiernos) podría generar amenazas repentinas si la comunidad blockchain +no actualiza con rapidez. + +### Otras consideraciones + +Barreras generales de adopción, incertidumbre regulatoria en +finanzas/blockchain y la volatilidad inherente de los ecosistemas cripto. + + + +
    + + + Shor, P. W. (1997). Polynomial-time algorithms for prime factorization and + discrete logarithms on a quantum computer. _SIAM Journal on Computing_, 26(5), + 1484–1509. https://doi.org/10.1137/S0097539795293172 + + + + Grover, L.K. (1996). A fast quantum mechanical algorithm for database search. + _Proceedings of the Twenty-Eight Annual ACM Symposium on Theory of Computing_, + 212-219. https://doi.org/10.1145/237814.237866 + + + + Chainalysis. (2024). _The Chainalysis 2024 Crypto Crime Report_. + https://www.chainalysis.com/blog/2024-crypto-crime-report-introduction/ + + + + National Institute of Standards and Technology. (2024). _FIPS 204: + Module-Lattice-Based Digital Signature Standard (ML- DSA)_. U.S. Department of + Commerce. https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf + + + + National Institute of Standards and Technology. (2024). _FIPS 203: + Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)_. U.S. + Department of Commerce. + https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf + + + + Häner, T., Jaques, S., Naehrig, M., Roetteler, M., & Soeken, M. (2020). + Improved quantum circuits for elliptic curve discrete logarithms. + _arXiv:2002.12480_. https://arxiv.org/abs/2002.12480 + + + + Gidney, C., & Ekerå, M. (2021). _How to factor 2048 bit RSA integers in 8 + hours using 20 million noisy qubits_. _arXiv:1905.09749_. + https://arxiv.org/abs/1905.09749 + + + + Aggarwal, D., et al. (2021). Assessment of Quantum Threat To Bitcoin and + Derived Cryptocurrencies. _ePrint IACR_. https://eprint.iacr.org/2021/967.pdf + + + + Roetteler, M., Naehrig, M., Svore, K. M., & Lauter, K. (2017). Quantum + resource estimates for computing elliptic curve discrete logarithms. + _arXiv:1706.06752_. https://arxiv.org/abs/1706.06752 + + + + Open Quantum Safe Project. (n.d.). ML-DSA | Open Quantum Safe. Retrieved + January 29, 2026, from + https://openquantumsafe.org/liboqs/algorithms/sig/ml-dsa.html + diff --git a/website/src/contents/whitepapers/hi-IN/v0.3.3.mdx b/website/src/contents/whitepapers/hi-IN/v0.3.3.mdx new file mode 100644 index 0000000..57c7bc2 --- /dev/null +++ b/website/src/contents/whitepapers/hi-IN/v0.3.3.mdx @@ -0,0 +1,711 @@ +--- +title: "Quantus Network Whitepaper" +version: "0.3.3" +publishedDate: "2026-03-21" +updatedDate: "2026-03-21" +authors: ["Christopher Smith"] +changelog: + - "व्यापक संशोधन: कानूनी अस्वीकरण, विषय-सूची, अध्याय संख्या (01–09), PDF कवर, TOC; समापन अनुभाग के बजाय संदर्भ व आगे पढ़ें।" + - "नया अध्याय: प्रवास संकट (समन्वय, खोए सिक्के, PQC प्रवास समयरेखा)।" + - "परिचय व क्वांटम खतरे के खंड फिर से लिखे: CRQC ढांचा, चार क्रमांकित खतरे, इनलाइन उद्धरण।" + - "वास्तुकला व तकनीकी खंड विस्तृत या स्पष्ट (Foundation/Substrate, LibP2P, wormhole/Plonky2, सहमति/Goldilocks)।" + - "रोडमैप: Bell मेननेट Q2 2026; Fermi अपग्रेड Q4 2026; Planck बीटा में ZK एकीकरण।" +pdfCover: true +# Astro `render().headings` में JSX `

    ` और ChapterHeading शामिल नहीं होते; एंकर slug Markdown `###` id से मेल खाते हैं। +toc: + insertBefore: + क्वांटम-खतरा: + - slug: legal-disclaimer + text: कानूनी अस्वीकरण + - slug: contents + text: विषय-सूची + - slug: chapter-01 + text: परिचय + क्वांटम-कंप्यूटिंग-की-मूल-बातें: + - slug: chapter-02 + text: ब्लॉकचेन के लिए क्वांटम खतरा + समन्वय-की-समस्या: + - slug: chapter-03 + text: प्रवासन संकट + आधार: + - slug: chapter-04 + text: Quantus Network वास्तुकला + प्रतिवर्तनीय-लेनदेन: + - slug: chapter-05 + text: धन संरक्षण + ब्लॉक-पुरस्कार: + - slug: chapter-06 + text: टोकनोमिक्स और शासन + कार्यान्वयन-समस्याएँ: + - slug: chapter-07 + text: रोडमैप + - slug: chapter-08 + text: जोखिम + insertAfter: + अन्य-विचार: + - slug: chapter-09 + text: संदर्भ और आगे पढ़ने के लिए +--- + +import CalloutV2 from "@/components/features/whitepaper/mdx/CalloutV2.astro"; +import Figure from "@/components/features/whitepaper/mdx/Figure.astro"; +import Grid from "@/components/features/whitepaper/mdx/Grid.astro"; +import Column from "@/components/features/whitepaper/mdx/Column.astro"; +import TimelineV2 from "@/components/features/whitepaper/mdx/TimelineV2.astro"; +import ResponsiveTableV2 from "@/components/features/whitepaper/mdx/ResponsiveTableV2.astro"; +import SiteSocials from "@/components/ui/SiteSocials.astro"; +import OrderedList from "@/components/features/whitepaper/mdx/OrderedList.astro"; +import Divider from "@/components/features/whitepaper/mdx/Divider.astro"; +import ChapterHeading from "@/components/features/whitepaper/mdx/ChapterHeading.astro"; +import Reference from "@/components/features/whitepaper/mdx/Reference.astro"; +import ReferenceMarker from "@/components/features/whitepaper/mdx/ReferenceMarker.astro"; + +

    + +_यह व्हाइटपेपर केवल सूचनात्मक उद्देश्यों के लिए प्रस्तुत किया गया है और +किसी प्रतिभूति, निवेश या वित्तीय उत्पाद की बिक्री का प्रस्ताव, खरीद के प्रस्ताव का आग्रह +या सिफारिश नहीं है। पाठकों को निवेश निर्णय लेने से पहले अपनी स्वयं की उचित जाँच करनी चाहिए और +योग्य पेशेवरों से परामर्श करना चाहिए। +Quantus Network यहाँ दी गई जानकारी की सटीकता या पूर्णता के संबंध में +कोई प्रतिनिधित्व या वारंटी नहीं देता।_ + +

    + विषय-सूची +

    + + + +
    + + + +### क्वांटम खतरा + +पारंपरिक ब्लॉकचेन क्रिप्टोग्राफ़िक रूप से प्रासंगिक क्वांटम कंप्यूटरों (CRQC) से +अस्तित्वगत खतरे का सामना करते हैं। ब्लॉकचेन की क्रिप्टोग्राफ़िक नींव +डिस्क्रीट लॉगरिदम समस्या (DLP) की कठिनता पर निर्भर करती है, और क्वांटम एल्गोरिदम, +विशेष रूप से शोर का एल्गोरिदम, DLP को शास्त्रीय कंप्यूटरों की तुलना में +घातीय रूप से तेज़ी से हल कर सकता है। यह भेद्यता प्रतिद्वंद्वियों को +सार्वजनिक कुंजियों से निजी कुंजी निकालने में सक्षम बना सकती है, जिससे वे +लेनदेन जाली बना सकें और संवेदनशील वित्तीय डेटा को डिक्रिप्ट कर सकें। + +> सक्रिय क्वांटम-प्रतिरोधी अपग्रेड के बिना, खरबों डॉलर की क्रिप्टो अर्थव्यवस्था +> ऐसे हमलों से अचानक अवमूल्यन का जोखिम उठाती है। + +### अनूठा मूल्य प्रस्ताव + +लैटिन शब्द से जिसका अर्थ «कितना» है, उसके नाम पर Quantus Network +क्वांटम-सुरक्षित अर्थ में निजी, स्केलेबल धन सक्षम करता है। Quantus सामान्य +स्मार्ट कॉन्ट्रैक्ट प्लेटफ़ॉर्म नहीं है। कुछ अत्यधिक परिष्कृत व्यंजनों वाले रेस्तरां की तरह, Quantus यह प्रदान करता है: + +- सभी लेनदेन के लिए पोस्ट-क्वांटम हस्ताक्षर +- पीयर कनेक्शन सुरक्षित करने के लिए पोस्ट-क्वांटम हस्ताक्षर और एन्क्रिप्शन (ML-DSA और ML-KEM) +- स्केल करने के लिए पोस्ट-क्वांटम ज़ीरो-नॉलेज प्रूफ +- चोरी को रोकने और गलतियों से उबरने के लिए उच्च सुरक्षा खाते +- पते सत्यापित करने में आसानी के लिए मानव-पठनीय चेक-फ़्रेज़ + +निजी, क्वांटम-सुरक्षित, स्केलेबल धन पर ध्यान केंद्रित करने का निर्णय +उद्योग के लिए CRQC द्वारा पेश खतरे और Bitcoin की इन चुनौतियों को संबोधित करने में असमर्थता से उत्पन्न होता है। + + + +### क्वांटम कंप्यूटिंग की मूल बातें + +क्वांटम कंप्यूटर सुपरपोज़िशन और उलझाव जैसे सिद्धांतों का उपयोग करके +ऐसी गणनाएँ करते हैं जो शास्त्रीय मशीनों के लिए अथक हैं। शास्त्रीय बिट्स के विपरीत, जो 0 या 1 होते हैं, +क्यूबिट एक साथ कई अवस्थाओं में हो सकते हैं, +जिससे कुछ समस्याओं के लिए घातीय समानांतरता मिलती है। यह +क्षमता ब्लॉकचेन वित्त को संरेखित करने वाली क्रिप्टोग्राफ़िक प्रणालियों के लिए अस्तित्वगत जोखिम पैदा करती है, क्योंकि क्वांटम +हार्डवेयर के लिए विकसित एल्गोरिदम अधिकांश सार्वजनिक-कुंजी क्रिप्टोग्राफ़ी की सुरक्षा धारणाओं को कमजोर करते हैं। + +**शोर का एल्गोरिदम**, 1994 में पीटर शोर द्वारा प्रस्तुत, बड़े पूर्णांकों के गुणनखंडन और क्वांटम कंप्यूटर पर +डिस्क्रीट लॉगरिदम समस्या को हल करने के लिए बहुपद-समय विधि प्रदान करता है। यह किसी फ़ंक्शन की अवधि खोजने के लिए क्वांटम फूरियर ट्रांसफ़ॉर्म (QFT) का उपयोग करता है, +जिससे RSA या दीर्घवृत्तीय वक्र क्रिप्टोग्राफ़ी (ECC) जैसी योजनाओं के आधार पर ट्रैपडोर फ़ंक्शनों को कुशलता से उलटने की अनुमति मिलती है। ब्लॉकचेन +वित्त के लिए, इसका अर्थ है कि पर्याप्त शक्तिशाली क्वांटम कंप्यूटर (~2,000 लॉजिकल क्यूबिट अनुमानित ) +वाला हमलावर बहुपद समय O(n³) में सार्वजनिक कुंजियों से निजी कुंजी निकाल सकता है: एक अत्यधिक त्वरण +जो रातोंरात कमजोर प्रणालियों को अप्रचलित कर देता है। + +**ग्रोवर का एल्गोरिदम**, लव ग्रोवर द्वारा 1996 में प्रस्तावित, असंरचित खोज के लिए +द्विघात त्वरण प्रदान करता है, खोज समय को O(n) से O(√n) संचालन तक कम करता है। यद्यपि यह असममित क्रिप्टोग्राफ़ी के लिए शोर जितना +विनाशकारी नहीं है, ग्रोवर +हैश फ़ंक्शन और AES एन्क्रिप्शन जैसे सममित प्रिमिटिव को प्रभावित करता है, +प्रभावी रूप से सुरक्षा स्तर को आधा कर देता है (उदा., 256-बिट कुंजी +क्वांटम हमलों के खिलाफ 128 बिट्स की तरह व्यवहार करती है)। इस हमले को +क्रिप्टोग्राफ़िक योजना बदलने के बजाय सुरक्षा बिट्स दोगुना करके कम किया जाता है। इसके अतिरिक्त, ग्रोवर का द्विघात त्वरण उच्च क्यूबिट और गेट आवश्यकताओं के कारण अव्यावहारिक है, +अरबों क्रमिक संचालन की आवश्यकता होती है सीमित समानांतरता के साथ, +जिससे भविष्य के हार्डवेयर पर भी वास्तविक दुनिया में उलटफेर असंभव हो जाता है। + +### चार खतरे की श्रेणियाँ + +#### 01 - डिजिटल हस्ताक्षर जाली बनाना + +शोर का एल्गोरिदम अधिकांश ब्लॉकचेन में उपयोग किए जाने वाले ECC-आधारित हस्ताक्षरों को सीधे खतरे में डालता है +(उदा., Bitcoin की secp256k1 वक्र), जिससे +प्रतिद्वंद्वियों को उपयोगकर्ताओं का रूप धारण करने और धोखाधड़ी वाले लेनदेन को अधिकृत करने की अनुमति मिलती है। ऐसी क्षमता ब्लॉकचेन की +सबसे बुनियादी विशेषता की गंभीर विफलता होगी। + +#### 02 - ज़ीरो-नॉलेज प्रणालियों में झूठे प्रमाण जाली बनाना + +कई ज़ीरो-नॉलेज प्रूफ, जैसे गोपनीयता-केंद्रित वित्त के लिए zk-SNARKs में, प्रतिबद्धताओं के लिए दीर्घवृत्तीय-वक्र पेयरिंग के माध्यम से डिस्क्रीट लॉगरिदम कठिनता पर निर्भर करते हैं। शोर अमान्य प्रमाण बनाने में सक्षम हो सकता है जो वैध दिखें, जिससे हमलावर नए सिक्के बना सकता है या लेयर 2 (L2) की स्थिति जाली बना सकता है। + +#### 03 - गुप्त जानकारी डिक्रिप्ट करना + +क्वांटम हमले Zcash या Monero जैसे गोपनीयता प्रोटोकॉल में कमजोर सार्वजनिक-कुंजी योजनाओं द्वारा संरक्षित एन्क्रिप्टेड डेटा को उजागर कर सकते हैं। वे वित्तीय प्रोटोकॉल में p2p संचार को भी डिक्रिप्ट कर सकते हैं, संवेदनशील धन विवरण प्रकट कर सकते हैं और लक्षित चोरी सक्षम कर सकते हैं। + +#### 04 - हैश फ़ंक्शन उलटना + +ग्रोवर का एल्गोरिदम SHA-256 जैसे हैश पर प्रीइमेज हमलों को तेज कर सकता है, जिनका उपयोग प्रूफ़-ऑफ़-वर्क और पता निर्माण में होता है, लेकिन +यह सबसे कम चिंताजनक खतरा है। कई पोस्ट-क्वांटम +क्रिप्टोग्राफ़िक योजनाएँ हैश-आधारित निर्माण शामिल करती हैं क्योंकि +पर्याप्त बड़े डाइजेस्ट के साथ हैश पर्याप्त सुरक्षित माने जाते हैं। + +### पोस्ट-क्वांटम क्रिप्टोग्राफ़ी में स्केलिंग चुनौतियाँ + +यद्यपि पोस्ट-क्वांटम क्रिप्टोग्राफ़ी (PQC) क्वांटम खतरों के खिलाफ आवश्यक +सुरक्षा प्रदान करती है, यह इन एल्गोरिदम के अंतर्निहित डिज़ाइन के कारण महत्वपूर्ण स्केलिंग बाधाएँ पेश करती है। +दीर्घवृत्तीय वक्र योजनाओं के विपरीत, जो संक्षिप्त गणितीय संरचनाओं पर निर्भर करती हैं, +PQC प्रिमिटिव को शास्त्रीय और क्वांटम दोनों प्रतिद्वंद्वियों के खिलाफ सुरक्षा बनाए रखने के लिए बड़े पैरामीटर चाहिए। इसके परिणामस्वरूप +सार्वजनिक कुंजी, निजी कुंजी और हस्ताक्षर काफ़ी बड़े हो जाते हैं, +अक्सर परिमाण के क्रम तक। निम्न तालिका +128-बिट पोस्ट-क्वांटम सुरक्षा स्तर पर ML-DSA के लिए विशिष्ट आकार दर्शाती है +256-बिट ECDSA जैसे शास्त्रीय समकक्षों की तुलना में: + + + +128-बिट पोस्ट-क्वांटम सुरक्षा स्तर पर आकार। स्रोत: Open +Quantum Safe Project + +जैसा दिखाया गया है, ML-DSA हस्ताक्षर ECDSA समकक्षों की तुलना में 70 गुना से अधिक बड़े हो सकते हैं, और सार्वजनिक कुंजियाँ 80 गुना से अधिक बड़ी। +अन्य PQC परिवार इसे बढ़ाते हैं: SPHINCS+ जैसी हैश-आधारित योजनाएँ +41 KB तक के हस्ताक्षर उत्पन्न कर सकती हैं, जबकि आकार-अनुकूलित जाली वेरिएंट +जैसे FALCON अभी भी शास्त्रीय आकारों से +काफ़ी अधिक गुणक पर हैं। + +ब्लॉकचेन संदर्भों में, ये बढ़े हुए आकार प्रणालीगत स्केलिंग मुद्दों में जुड़ जाते हैं। बड़े हस्ताक्षर व्यक्तिगत लेनदेन को फुलाते हैं, +प्रति सेकंड लेनदेन (TPS) कम करते हैं क्योंकि ब्लॉक +तेज़ी से भरते हैं और सत्यापन में अधिक समय लगता है। यह पीयर-टू-पीयर (P2P) संचार को भी तनाव देता है, बैंडविड्थ और +प्रसार में देरी बढ़ाता है, जो प्रूफ़-ऑफ़-वर्क जैसे सर्वसम्मति तंत्र में नेटवर्क फोर्क या +अनाथ ब्लॉकों के जोखिम को बढ़ा सकता है। +भंडारण आवश्यकताएँ भी प्रभावित होती हैं, उच्च नोड परिचालन लागत और भागीदारी में बाधाएँ, विशेष रूप से +संसाधन-सीमित उपयोगकर्ताओं या सत्यापनकर्ताओं के लिए। + + + इन स्केलिंग चुनौतियों को भविष्य में सभी ब्लॉकचेन को संबोधित करना होगा। उदाहरण + के लिए, यदि अधिकतम ब्लॉक आकार नहीं बढ़ाया जाता है तो Bitcoin में 1 TPS से कहीं + कम होगा। + + + + +### समन्वय की समस्या + +Bitcoin की रूढ़िवादी संस्कृति प्रोटोकॉल परिवर्तनों का विरोध करती है। कोई भी PQC +अपग्रेड प्रवासन समयसीमा, संभावित सिक्का जब्ती और ब्लॉक आकार +वृद्धि जैसे विवादास्पद मुद्दों पर सर्वसम्मति माँगेगा। यदि समुदाय सहमत भी हो, हर उपयोगकर्ता को +अपने सिक्के नए क्वांटम-सुरक्षित पतों पर ले जाने होंगे। +प्रवासन के लिए हर क्रिप्टो धारक की कार्रवाई चाहिए, +जिनमें से कई ने अपने वॉलेट तक पहुँच खो दी है या खतरे से अनजान हैं। + +ये मुद्दे हर सार्वजनिक ब्लॉकचेन के लिए मौजूद हैं, लेकिन Bitcoin के लिए अद्वितीय रूप से +कठिन हैं क्योंकि स्पष्ट नेतृत्व की कमी है और +तकनीकी अवसादन की दार्शनिकता। + +### खोए हुए सिक्कों की समस्या + +अनुमान है कि $250 अरब से $500 अरब तक का Bitcoin +खोई कुंजियों, मृत धारकों या भूले वॉलेटों के कारण स्थायी रूप से अप्राप्य है। [3] ये सिक्के प्रवासित नहीं किए जा सकते और क्रिप्टोग्राफ़िक रूप से प्रासंगिक +क्वांटम कंप्यूटर (CRQC) बनाने के लिए सार्वजनिक इनाम के रूप में काम करते हैं। क्वांटम हमलावर प्रवासित नहीं की गई सार्वजनिक कुंजियों से निजी कुंजी निकालेंगे और संभवतः अरबों +डॉलर BTC बाज़ार में डंप करेंगे। + +> एकमात्र तकनीकी समाधान के लिए सख्त अंतिम तिथि चाहिए +> जो अप्रवासित सिक्कों को जमा कर दे: एक +> राजनीतिक असंभवता। + +ऐसी अंतिम तिथि के बिना, परिणाम यह होगा कि अप्रवासित +सिक्के चुराए और बेचे जाएँगे, बाज़ार ध्वस्त होगा और +नेटवर्क में विश्वास नष्ट होगा। + +### प्रवासन समयरेखा की समस्या + +पोस्ट-क्वांटम हस्ताक्षर वर्तमान Bitcoin हस्ताक्षरों से 20 से 80 गुना बड़े हैं। +मौलिक वास्तुकला परिवर्तन के बिना, Bitcoin का थ्रूपुट +पहले से सीमित क्षमता के एक अंश तक गिर जाएगा। + +मान लें Bitcoin राजनीतिक और तकनीकी चुनौतियाँ हल कर लेता है, स्वयं +प्रवासन में महीने या साल लगेंगे। हर धारक को कम से कम एक लेनदेन भेजना होगा ताकि धन क्वांटम-सुरक्षित +पते पर जाए। कई पहले परीक्षण लेनदेन भेजेंगे। फूले हुए PQC हस्ताक्षर थ्रूपुट को दबाते हुए, नेटवर्क महीनों या सालों तक कतार का सामना करता है जबकि क्वांटम-संवेदनशील सिक्के खुले रहते हैं। + + + ये संचित चुनौतियाँ मौजूदा चेन पर क्वांटम सुरक्षा जोड़ना असाधारण रूप से कठिन + बनाती हैं। Quantus Network इसे पहले दिन से चेन में क्वांटम सुरक्षा बनाकर बचाता + है। + + + + +### आधार + +Quantus Network Substrate पर बना है, एक ब्लॉकचेन SDK +जिसे Parity Technologies ने विकसित किया, Ethereum और +Polkadot के पीछे की टीम। Substrate अत्यधिक मॉड्युलर है, जिससे घटकों को आसानी से बदला जा सकता है ताकि हम Quantus को अनूठा बनाने वाली चीज़ों पर ध्यान दें। + +Quantus Substrate को बेहतर बनाता है: + +- पोस्ट-क्वांटम हस्ताक्षर योजनाओं के लिए समर्थन जोड़कर +- p2p नेटवर्किंग सुरक्षा को पोस्ट-क्वांटम बनाकर +- उपयोगकर्ता-नियंत्रित लेनदेन प्रतिवर्तनीयता जोड़कर +- सभी डेटा प्रकारों को फ़ील्ड-तत्व सीमाओं के साथ संरेखित करके डेटाबेस को zk-अनुकूल बनाकर + +### पोस्ट-क्वांटम क्रिप्टोग्राफ़िक प्रिमिटिव + +Quantus Network लेनदेन और नेटवर्क संचार की सुरक्षा सुनिश्चित करने के लिए NIST-मानकीकृत PQC का उपयोग करता है +क्वांटम खतरों के खिलाफ। लेनदेन अखंडता के केंद्र में **ML-DSA** +(मॉड्यूल-जाली-आधारित डिजिटल हस्ताक्षर एल्गोरिदम, पहले CRYSTALS-Dilithium के नाम से जाना जाता था) है, एक जाली-आधारित हस्ताक्षर योजना जिसे सुरक्षा, दक्षता और कार्यान्वयन में आसानी के संतुलन के लिए चुना गया। ML-DSA LWE और SIS जैसी समस्याओं की कठिनता का उपयोग करता है +मॉड्यूल जालियों पर, शास्त्रीय और क्वांटम दोनों हमलों के प्रति मजबूत प्रतिरोध प्रदान करता है, +शोर के एल्गोरिदम सहित। + +लेनदेन हस्ताक्षरों के लिए, Quantus **ML-DSA-87** एकीकृत करता है, पैरामीटर सेट जो उच्चतम सुरक्षा स्तर प्रदान करता है (NIST सुरक्षा स्तर 5, +256-बिट शास्त्रीय और 128-बिट क्वांटम सुरक्षा के समकक्ष) +संभावित क्रिप्टोएनालिटिक सफलताओं से बचाने के लिए जाली समस्याओं में। यह विकल्प सावधानी को प्राथमिकता देता है, क्योंकि जाली क्रिप्टोग्राफ़ी अपेक्षाकृत नई है और शास्त्रीय योजनाओं की तुलना में कम युद्ध-परीक्षित है। बड़े पैरामीटर जाली क्रिप्टोएनालिसिस में संभावित प्रगति के जोखिम कम करते हैं, जो अभी भी छोटे कुंजी आकारों को नरम लक्ष्य छोड़ देंगे। + +#### विचार किए गए विकल्प + +ML-DSA को FN-DSA (Falcon) जैसे विकल्पों पर चुना गया क्योंकि FN-DSA की अधिक कार्यान्वयन जटिलता (उदा., फ़्लोटिंग-पॉइंट संचालन, ब्लॉकचेन-अनुकूल नहीं), विनिर्देश में नियतात्मक कुंजी निर्माण की कमी और विकास के समय गैर-अंतिम स्थिति। + +SLH-DSA जैसी हैश-आधारित विकल्प उनके और भी बड़े हस्ताक्षर (17 KB से अधिक) के कारण नहीं चुने गए। क्रिप्टो-चपलता +(विभिन्न हस्ताक्षर योजनाएँ बदलने की क्षमता) Substrate में निर्मित है, +इसलिए भविष्य में परिस्थितियों की माँग पर ये विकल्प जोड़ना अपेक्षाकृत सरल है। + +यद्यपि ML-DSA-87 बड़ी कुंजियाँ और हस्ताक्षर उत्पन्न करता है, ये Quantus के प्रारंभिक चरण के नेटवर्क में प्रबंधनीय हैं, जहाँ भंडारण अभी तक अड़चन नहीं है, और ज़ीरो-नॉलेज प्रूफ के माध्यम से वर्महोल पते जैसे अनुकूलन स्केलिंग संबोधित करेंगे। + +कार्यान्वयन के तकनीकी विवरण के लिए [QIP-0006](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0006.md) देखें। + +### LibP2P - क्वांटम-सुरक्षित नेटवर्किंग + +Quantus Network पीयर-टू-पीयर (P2P) नोड संचार को सुरक्षित करता है +ML-DSA को प्रमाणीकरण के लिए और एन्क्रिप्शन के लिए **ML-KEM** (मॉड्यूल-जाली-आधारित कुंजी एनकैप्सुलेशन मैकेनिज़्म, +पहले CRYSTALS-Kyber) के संयोजन से। यह एकीकरण PQC को libp2p स्टैक तक विस्तारित करता है, क्वांटम प्रतिरोध के लिए मुख्य घटकों को संशोधित करता है: पीयर पहचान के लिए ML-DSA-87 हस्ताक्षर और परिवहन सुरक्षा के लिए ML-KEM-768 +(क्वांटम-प्रतिविरोधी साझा रहस्यों के लिए अतिरिक्त KEM संदेश के साथ Noise हैंडशेक विस्तारित करना)। + +P2P परत को अक्सर क्वांटम-सुरक्षा विश्लेषण में नज़रअंदाज़ किया जाता है। +पीयर प्रमाणीकरण महत्वपूर्ण है, लेकिन पीयर स्तर पर हमलावर सबसे बुरा नोड का रूप धारण करके अमान्य संदेश भेज सकता है, +जिससे सेवा से इनकार हो सकता है। यह हमला पहले से कम है क्योंकि ब्लॉकचेन मॉडल में नोड्स आम तौर पर अविश्वसनीय होते हैं और हमले का पता चलने पर आसानी से कुंजी बदल सकते हैं। इसी तरह, P2P संचार डिक्रिप्ट करने से हमलावर को सीमित लाभ (उदा., लेनदेन पथ ट्रैक करना, प्रॉक्सी या Tor से कम), और अधिकांश डेटा वैसे भी ऑन-चेन सार्वजनिक हो जाता है। + +फिर भी, P2P परत को क्वांटम-सुरक्षित करना छिपकर सुनने, मध्यस्थ हमलों और क्वांटम +डिक्रिप्शन से बचाता है, यह सुनिश्चित करता है कि नोड गॉसिप, ब्लॉक प्रसार और +अन्य नेटवर्क इंटरैक्शन निकट भविष्य में गोपनीय और छेड़छाड़-रहित रहें। + +तकनीकी विवरण के लिए [QIP-0004](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0004.md) देखें। + +### PQC स्केलिंग - वर्महोल पते + +पोस्ट-क्वांटम क्रिप्टोग्राफ़ी में अंतर्निहित स्केलिंग चुनौतियों का समाधान करने के लिए, Quantus Network एक नवीन एकत्रित पोस्ट-क्वांटम हस्ताक्षर योजना पेश करता है जिसे **«वर्महोल पते»** कहा जाता है। +यह प्रणाली Plonky2 प्रूफिंग सिस्टम (मूलतः STARKs) के माध्यम से उत्पन्न ज़ीरो-नॉलेज प्रूफ (ZKP) का उपयोग करती है ताकि +शेष सत्यापन ऑफ-चेन हो, जिससे चेन एक ही संक्षिप्त प्रूफ सत्यापित कर सके बिना व्यक्तिगत हस्ताक्षर संसाधित किए। वर्महोल पते एक प्रूफ के साथ बड़ी संख्या में +लेनदेन सत्यापित करने देते हैं, सार्वजनिक इनपुट (उदा., nullifiers, +स्टोरेज रूट, निकास पते और राशि) प्राथमिक सीमक बन जाते हैं। यह प्रति-लेनदेन भंडारण माँग को लगभग 256 अतिरिक्त बाइट प्रति लेनदेन तक कम करता है, +किसी भी ज्ञात PQC हस्ताक्षर योजना से कहीं छोटा। + +योजना की क्वांटम सुरक्षा FRI (फास्ट रीड-सोलोमन इंटरैक्टिव ओरेकल प्रूफ) के माध्यम से प्रतिबद्धताओं के लिए सुरक्षित हैश फ़ंक्शन **Poseidon2** के उपयोग से आती है, SNARKs में आमतौर पर उपयोग किए जाने वाले क्वांटम-संवेदनशील दीर्घवृत्तीय-वक्र पेयरिंग के बजाय। + +इसके अतिरिक्त, प्रमाणीकरण रहस्य Poseidon2 के पीछे छिपे रहते हैं। चूँकि सुरक्षित हैश फ़ंक्शन केवल ग्रोवर के एल्गोरिदम से द्विघात रूप से कमजोर होते हैं, टूटते नहीं, हैश प्रीइमेज प्रूफ +ZK संदर्भों में हल्के पोस्ट-क्वांटम हस्ताक्षर के रूप में काम कर सकते हैं, +SPHINCS+ जैसी हैश-आधारित योजनाओं के समान। + +#### क्लाइंट / प्रूवर प्रवाह + +उपयोगकर्ता एक नमक को गुप्त के साथ जोड़कर दोहरा-हैश करके प्रमाणित रूप से अखर्च योग्य पता बनाते हैं: + +``` +H(H(salt|secret)) +``` + +यह संरचना झूठे सकारात्मक (उदा., सरल-हैश सार्वजनिक कुंजी को अखर्च योग्य पते से भ्रमित करना) रोकती है क्योंकि Substrate में +(और सामान्यतः) ब्लॉकचेन पते सार्वजनिक कुंजी का सरल हैश होते हैं जो निजी कुंजी से किसी बीजगणितीय +संक्रिया से प्राप्त होते हैं, सुरक्षित हैश से नहीं। संरचना की सुरक्षा इसलिए +सुरक्षित हैश की प्रीइमेज-ऑफ़-प्रीइमेज खोजने तक सिमट जाती है। इस पते पर भेजे गए टोकन प्रभावी रूप से जल जाते हैं। +वे खर्च नहीं किए जा सकते क्योंकि प्राप्तकर्ता पते के लिए निजी कुंजी मौजूद नहीं है। ये सिक्के पुनः मिंट किए जा सकते हैं +बिना आपूर्ति बढ़ाए। + +प्रत्येक स्थानांतरण के लिए एक TransferProof स्टोरेज ऑब्जेक्ट बनाया जाता है, +विवरण जैसे वैश्विक अद्वितीय स्थानांतरण गिनती। उपयोगकर्ता का वॉलेट +हाल के ब्लॉक हेडर की स्टोरेज रूट से इस TransferProof की पत्ती तक Merkle-Patricia-Trie (MPT) स्टोरेज प्रूफ उत्पन्न करता है। +डबल-स्पेंड रोकने के लिए nullifier गणना की जाती है: + +``` +H(H(salt | secret | global_transfer_count)) +``` + +#### एग्रीगेटर प्रवाह + +कोई भी पक्ष (क्लाइंट, माइनर या तीसरा) Plonky2 पुनरावृत्ति से कई +प्रूफ एकत्र कर सकता है, प्रूफ का वृक्ष बनाता है जहाँ +प्रत्येक मूल प्रूफ संतानों को सत्यापित करता है, संतान प्रूफ के सार्वजनिक इनपुट एकत्रित: + +- Nullifiers अपरिवर्तित पारित होते हैं +- निकास पते डिडुप्लिकेट होते हैं +- ब्लॉक हैश लिंक सिद्ध होते हैं फिर सबसे हाल के को छोड़कर छोड़ दिए जाते हैं +- डुप्लिकेट निकास पतों की राशियाँ जोड़ी जाती हैं + +#### चेन / सत्यापक प्रवाह + +नेटवर्क एकत्रित प्रूफ सत्यापित करता है: ब्लॉक हैश +चेन पर है और हाल का है, nullifier अद्वित्व (डबल-स्पेंड रोकने के लिए), और प्रूफ वैधता। ZK सर्किट स्टोरेज प्रूफ +सही होना, nullifier गणना, पते की अखर्च योग्यता, +इनपुट और आउटपुट के बीच शेष मिलान और +ब्लॉक हेडर लिंकेज लागू करता है। + +#### Plonky2 क्यों + +- पहले से ऑडिट किया गया +- पोस्ट-क्वांटम +- कोई विश्वसनीय सेटअप नहीं +- कुशल प्रूफ/सत्यापन +- निर्बाध प्रूफ एकत्रण +- Rust-मूल कार्यान्वयन +- Substrate के no-std वातावरण के साथ संगत + + + पुनरावर्ती प्रूफ 170 मिलीसेकंड में पूर्ण होते हैं संक्षिप्त आकार के साथ (प्रति + एकत्रित प्रूफ 100 KB)। 5 MB ब्लॉक और सभी लेनदेन एक ही आउटपुट की ओर जाने के + इष्टतम मामले में, वर्महोल पते एक ब्लॉक में ~153,000 लेनदेन पैक कर सकते हैं + (4.9 MB / प्रति nullifier 32 बाइट): ~685 कच्चे ML-DSA लेनदेन (प्रत्येक 7.3 KB, + 5 MB) पर 223x सुधार। + + +#### सुरक्षा नोट्स + +संभावित जोखिमों में सर्किट/सत्यापन कार्यान्वयन दोषों से मुद्रास्फीति बग शामिल हैं, +हालाँकि यदि पुनः-मिंटेड सिक्के शून्य-भेज पतों के शेष से अधिक हों तो यह आर्थिक रूप से पता चल सकता है। उपयोगकर्ता वैकल्पिक रूप से प्रकाशित करके सिद्ध कर सकते हैं कि पता वर्महोल है +पहला हैश बिना गुप्त प्रकट किए। सत्यापन लेनदेन हस्ताक्षरित नहीं हैं, इसलिए विफल लेनदेन के माध्यम से सेवा से इनकार को +वित्तीय साधनों के बिना कम किया जाना चाहिए। टोकन आपूर्ति गणना +बनी रहती है, क्योंकि पुनः-मिंट नए सिक्कों की तरह दिखते हैं लेकिन जलाने के माध्यम से अधिकतम आपूर्ति गारंटी बनाए रखते हैं। + +अधिक तकनीकी विवरण के लिए [QIP-0005](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0005.md) देखें। + +### सर्वसम्मति तंत्र + +Quantus Network प्रूफ़-ऑफ़-वर्क (PoW) सर्वसम्मति एल्गोरिदम का उपयोग करता है +जो Bitcoin सर्वसम्मति के वांछनीय गुण संरक्षित करता है +जबकि ZK-प्रूफ प्रणालियों के साथ अनुकूलता सुधारता है **Poseidon2** के साथ SHA-256 बदलकर। + +महत्वपूर्ण: यह परिवर्तन क्वांटम सुरक्षा के लिए नहीं किया जाता। +SHA-256 जैसी क्रिप्टोग्राफ़िक हैश फ़ंक्शन क्वांटम एल्गोरिदम, विशेष रूप से ग्रोवर, से कमजोर होते हैं लेकिन नष्ट नहीं होते। कुछ पोस्ट-क्वांटम हस्ताक्षर +योजनाएँ इस कारण सुरक्षित हैश को बुनियादी ब्लॉक के रूप में उपयोग करती हैं। + +Poseidon2 Poseidon हैश फ़ंक्शन का परिष्करण है। SHA-256 जैसी पारंपरिक हैश +वाली गणनाओं के लिए SNARKs या STARKs बनाना अक्सर Poseidon की तुलना में लगभग 100 गुना अधिक +गेट चाहता है, जो पूरी तरह बीजगणितीय फ़ंक्शन पर निर्भर करता है +फ़ील्ड तत्वों पर, बिट-स्तर संचालन के बजाय। + +हम Poseidon2 और Plonky2 दोनों के लिए **गोल्डीलॉक्स फ़ील्ड** का उपयोग करते हैं। गोल्डीलॉक्स फ़ील्ड का क्रम अहस्ताक्षरित 64-बिट पूर्णांक में फिट होता है, जिससे +ध्वनिता से समझौता किए बिना दक्षता बढ़ती है। + + + +क्रिप्टोकरेंसी कुंजियों के प्रबंधन में कई जोखिम हैं। अधिकांश +टाले जा सकते हैं। + +### प्रतिवर्तनीय लेनदेन + +Quantus Network उपयोगकर्ता-कॉन्फ़िगर करने योग्य प्रतिवर्तनीय लेनदेन प्रदान करता है। +प्रेषक एक समय खिड़की निर्धारित करते हैं जिसमें वे आउटगोइंग स्थानांतरण रद्द कर सकते हैं। +यह चोरी को रोकता है और अंतिमता बलिदान किए बिना त्रुटियाँ सुधारता है। प्रणाली टाइमस्टैम्प के साथ संशोधित Substrate «scheduler» पैलेट का उपयोग करती है। वॉलेट प्रेषक के लिए (रद्द बटन के साथ) और प्राप्तकर्ता दोनों के लिए उलटी गिनती दिखाते हैं। + +प्रतिवर्तनीय लेनदेन ऑन-चेन प्रवर्तन के माध्यम से विकेंद्रीकरण बनाए रखते हुए नवीन सुरक्षा प्रोटोकॉल सक्षम करते हैं। + +अधिक तकनीकी विवरण के लिए [QIP-0009](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0009.md) देखें। + +### चेक-फ़्रेज़ + +Quantus Network «चेक-फ़्रेज़» पेश करता है, ब्लॉकचेन पतों के लिए क्रिप्टोग्राफ़िक रूप से +सुरक्षित मानव-पठनीय चेकसम। पता हैश करके BIP-39 म्नेमोनिक सूची से यादगार शब्दों की छोटी श्रृंखला उत्पन्न होती है। चेक-फ़्रेज़ टाइपो, छेड़छाड़ और पता विषाक्तता हमलों से बचाते हैं। 50,000 पुनरावृत्ति कुंजी व्युत्पन्न फ़ंक्शन +इंद्रधनुष तालिका हमलों को महंगा बनाता है। बड़े लेनदेन के लिए, उपयोगकर्ताओं को अभी भी पते के प्रत्येक +अक्षर की जाँच करनी चाहिए। + +अधिक तकनीकी विवरण के लिए [QIP-0008](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0008.md) देखें। + +### उच्च सुरक्षा खाते + +कोई भी खाता सभी आउटगोइंग स्थानांतरणों पर अनिवार्य प्रतिवर्तन अवधि के साथ «उच्च सुरक्षा खाते» में उन्नत किया जा सकता है। नामित **गार्जियन** +(हार्डवेयर वॉलेट, मल्टीसिग या विश्वसनीय तीसरा पक्ष) प्रतिवर्तन अवधि के दौरान संदिग्ध लेनदेन रद्द कर सकता है, +धन प्रेषक या प्राप्तकर्ता के बजाय गार्जियन को भेजकर। यह ऑप्ट-इन सुविधा एक बार सक्रिय होने के बाद स्थायी है, चोरों को इसे बंद करने से रोकती है। + +गार्जियन चेन किए जा सकते हैं: उच्च सुरक्षा खाते का गार्जियन स्वयं अपने गार्जियन वाला उच्च सुरक्षा खाता हो सकता है। यह संयोज्य पदानुक्रम बनाता है जहाँ प्रत्येक गार्जियन की सुरक्षित खाते पर श्रेष्ठ अनुमतियाँ होती हैं। डिज़ाइन उपयोगकर्ताओं को अनधिकृत गतिविधि का पता लगाने और प्रतिक्रिया करने का समय देता है बिना वैध स्थानांतरणों की अंतिमता से समझौता किए। + +अधिक तकनीकी विवरण के लिए [QIP-0011](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0011.md) देखें। + +### कुंजी पुनर्प्राप्ति + +कई क्रिप्टो संपत्तियाँ मालिकों के साथ कब्र में चली गईं। +Quantus Network पुनर्प्राप्ति पता निर्दिष्ट करने का सरल तरीका प्रदान करता है जो किसी भी समय आपके धन खींच सकता है, निश्चित विलंब के अधीन। इस +दौरान, मालिक कुंजी तक पहुँच होने पर पुनर्प्राप्ति अस्वीकार कर सकता है। यह सुविधा उत्तरजीविता सक्षम करती है: उपयोगकर्ताओं के पास ऑन-चेन वसीयत है +बिना अदालत या औपचारिक एस्टेट। + +### HD-Lattice + +पदानुक्रमित नियतात्मक (HD) वॉलेट उद्योग मानक हैं +ब्लॉकचेन के लिए, एक बीज वाक्यांश से सभी कुंजियों का बैकअप, प्रति क्रिया मैनुअल बैकअप की तुलना में सुरक्षा और सुविधा बेहतर। Dilithium जैसी जाली योजनाओं के लिए इसे अनुकूलित करने में दो +चुनौतियाँ: + +- HMAC-SHA512 आउटपुट सीधे जाली निजी कुंजी नहीं बना सकते, + जो कुछ गुणों वाले रिंग से नमूना लिए गए बहुपद हैं। +- गैर-कठोर कुंजी व्युत्पत्ति दीर्घवृत्तीय वक्र जोड़ पर निर्भर करती है, + जालियों में अनुपस्थित (सार्वजनिक कुंजियाँ किसी बीजगणितीय संक्रिया के तहत बंद नहीं)। + +Quantus Network पहले बिंदु को HMAC आउटपुट को एन्ट्रॉपी के रूप में उपयोग करके संबोधित करता है ताकि नियतात्मक रूप से निजी कुंजी बनाई जा सके, +स्वयं कुंजी के रूप में नहीं। दूसरा बिंदु कम महत्वपूर्ण है और +अनुसंधान का खुला प्रश्न रहता है कि क्या जाली क्रिप्टोग्राफ़ी +इसे हल करने के लिए अनुकूलित की जा सकती है। + +अधिक तकनीकी विवरण के लिए [QIP-0002](https://github.com/Quantus-Network/improvement-proposals/tree/main/qip-0002) देखें। + + + +Quantus Network बदलते वातावरण में मौजूद है और हम नहीं +मान सकते कि पहली कोशिश में सब सही होगा। इसलिए हम एक +सरल प्रारंभिक बिंदु चुनते हैं और शासन प्रणाली को नई जानकारी मिलने पर +परिवर्तन करने देते हैं। यह डिज़ाइन ब्लॉकचेन को जीवित संस्था बनाता है जो +अपने वातावरण के अनुकूल हो सकती है। विशेष रूप से, Substrate शासन प्रक्रिया +विभिन्न नोड ऑपरेटरों के बीच न्यूनतम समन्वय के साथ चेन में गहरे परिवर्तन की अनुमति देती है। + +### ब्लॉक पुरस्कार + +Quantus Network Bitcoin की तरह सरल टोकनोमिक्स मॉडल का उपयोग करता है। अधिकतम आपूर्ति **21,000,000 सिक्के** है और सरल ह्यूरिस्टिक +प्रति ब्लॉक पुरस्कार निर्धारित करता है: + +``` +block_reward = (max_supply - current_supply) / constant +``` + +यह ह्यूरिस्टिक चिकनी घातीय घटती वक्र बनाता है जैसे +block_reward current_supply में योगदान करता है, जो अगले ब्लॉक पर गणना block_reward कम करता है। शुल्क या अन्य से कोई भी जल current_supply कम करता है और अनिवार्य रूप से ब्लॉक पुरस्कार बजट का हिस्सा बन जाता है। स्थिरांक इस तरह चुना गया है कि, बिना किसी जलने के, लगभग 30 +वर्षों में 99% सिक्के जारी हों। + +### निवेशक आवंटन + +Quantus Network निवेशकों की सहायता से बना जिन्होंने इसे वित्तपोषित करने में बड़ा जोखिम उठाया। निजी निवेशक 4 वर्ष की वेस्टिंग अनुसूची के अधीन हैं, +टीम की तरह। सार्वजनिक बिक्री के निवेशक पहले दिन से पूरी तरल होंगे। सार्वजनिक बिक्री में एकत्रित धन +टोकन के साथ मिलाए जाएँगे और तरलता (DEX, CEX और मार्केट +मेकर) के लिए उपयोग होंगे। ये निवेशक आवंटन साथ ही तरलता एकमात्र «प्री-माइन» होंगे। शेष टोकन को माइन करके +अस्तित्व में लाना होगा। + +यदि सार्वजनिक बिक्री के दौरान अधिकतम 10% से कम बिकता है, +तरलता टोकन में समानुपातिक कमी होगी और शेष ब्लॉक +पुरस्कारों के माध्यम से माइनरों को जारी होगा। + +### कंपनी आवंटन + +टीम को बिना सफलता की गारंटी के नई तकनीकी बनाने के जोखिम के लिए क्षतिपूर्ति करने के लिए, लगभग चार वर्षों तक ब्लॉक पुरस्कार का एक हिस्सा कंपनी को जाता है। इससे कंपनी के लिए कुल आपूर्ति के लगभग **15%** की वेस्टिंग अनुसूची de facto मिलती है। + +उस बिंदु के बाद, ब्लॉक पुरस्कार में कंपनी का हिस्सा +टोकन धारक वोट के अनुसार बंद, समायोजित या पुनर्निर्देशित किया जा सकता है। + +### लेनदेन शुल्क + + + +### बिना-फोर्क अपग्रेड + +Quantus Network Substrate रनटाइम अपग्रेड के माध्यम से «बिना-फोर्क» अपग्रेड का समर्थन करता है, जिससे ब्लॉकचेन की मुख्य तर्क +(«रनटाइम») बिना हार्ड फोर्क के विकसित हो सकती है जो नेटवर्क को विघ्नित करे या समुदाय विभाजित करे। यह ऑन-चेन शासन जनमत संग्रह के माध्यम से हासिल होता है, जहाँ अनुमोदित प्रस्ताव रनटाइम +स्वैप सक्रिय करते हैं — मौजूदा WASM कोड ब्लॉब को एक ब्लॉक में नए से प्रतिस्थापित करना, स्थिति और +संचालन की निरंतरता सुनिश्चित करना। यह मार्ग निष्क्रियता और जोखिम कम करता है, +समुदाय को वास्तविक उपयोग सुधार प्रकट करने पर प्रोटोकॉल को पुनरावृत्त रूप से परिष्कृत करने सशक्त बनाता है। + +जैसे-जैसे समुदाय समय के साथ प्रणाली में विश्वास बढ़ाता है, +रनटाइम बदलने की शक्ति काफ़ी कम कर दी जाएगी हमले की सतह सीमित करने के लिए, यदि दुर्भावनापूर्ण अभिनेता +अपग्रेड प्रक्रिया पर नियंत्रण प्राप्त कर ले। + +### शासन प्रणाली + +Quantus Network Substrate के माध्यम से Polkadot के OpenGov से अपना शासन ढाँचा विरासत में लेता है। टोकन धारक +**विश्वास वोटिंग** के माध्यम से भाग लेते हैं, जहाँ वे वोट के भार को बढ़ाने के लिए विभिन्न अवधियों के लिए संपत्ति लॉक करने पर सहमत होते हैं। यह प्रवर्धन 1x (बिना लॉक) से 6x (अधिकतम लॉकअप) तक हो सकता है। यह डिज़ाइन प्रतिबद्धता से प्रभाव जोड़कर दीर्घकालिक संरेखण को प्रोत्साहित करता है। + +प्रस्ताव कई वोटिंग ट्रैक में वर्गीकृत होते हैं जिन्हें +«उत्पत्ति» कहा जाता है। प्रत्येक उत्पत्ति के अनुकूल पैरामीटर होते हैं जैसे अनुमोदन सीमा +(उदा., उच्च प्रभाव परिवर्तनों के लिए सुपरमेजॉरिटी), स्पैम विरुद्ध न्यूनतम जमा, तैयारी/लागू अवधि और +निर्णय समयसीमा ग्रिडलॉक रोकने के लिए। यह बहु-ट्रैक डिज़ाइन +विविध जनमत संग्रह समानांतर संसाधित करने देता है, रूटीन ट्रेजरी खर्च से +महत्वपूर्ण रनटाइम अपग्रेड तक। + +**तकनीकी सामूहिक** तकनीकी विशेषज्ञों का क्यूरेटेड समूह है +जो तत्काल तकनीकी मामलों का प्रस्ताव, समीक्षा या व्हाइटलिस्ट करने के लिए विशेष निकाय के रूप में कार्य करता है, +समर्पित ट्रैक के माध्यम से तेज़ करते हुए समुदाय की निगरानी बनाए रखता है। + +Quantus इस प्रणाली को बिना संशोधन अपनाता है लेकिन प्रारंभिक चरणों में जटिलता से बचने के लिए न्यूनतम सेटअप से शुरू करता है। प्रारंभ में, +केवल तकनीकी सामूहिक ट्रैक सक्रिय है, जिसका उपयोग प्रोटोकॉल अपग्रेड या +पैरामीटर समायोजन जैसे बाध्यकारी, उच्च-विशेषाधिकार निर्णयों के लिए होगा। + +बाद में, Quantus गैर-बाध्यकारी समुदाय वोट ट्रैक जोड़ सकता है +लागू न करने योग्य विषयों पर भावना जाँचने के लिए, जैसे सुविधा सुझाव +या पारिस्थितिकी सर्वेक्षण। जब कंपनी नेटवर्क DAO को सौंप देगी तो यह प्रणाली बाध्यकारी हो जाएगी। यह चरणबद्ध +दृष्टिकोण भविष्य के शासन वोट के माध्यम से नेटवर्क को जैविक रूप से विकसित होने देता है +बिना शुरुआत में अनावश्यक जटिलता उपयोगकर्ताओं पर लादे। + + + +2026 तक वर्तमान रोडमैप, परिवर्तन के अधीन। + + + + + + + + + + + + + + + +
    + + + +Quantus Network बनाने में अंतर्निहित जोखिम हैं। + +### कार्यान्वयन समस्याएँ + +सॉफ़्टवेयर तर्क में दोष गंभीर विफलता का कारण बन सकते हैं यहाँ तक कि सर्वोत्तम +डिज़ाइन की प्रणालियों में भी। + +### NIST एल्गोरिदम चयन समस्याएँ + +चयनित पोस्ट-क्वांटम मानकों में संभावित दोष या बैकडोर +(उदा., ML-DSA, ML-KEM) जो मानकीकरण के बाद सामने आ सकते हैं। सबसे बुरे मामले में, ऐसे दोष हमलावर को सार्वजनिक से निजी कुंजी निकालकर हस्ताक्षर जाली बनाने देंगे, जो चेन की विनाशकारी विफलता मोड होगी। यदि ऐसे दोष सार्वजनिक हों, Quantus Network नए एल्गोरिदम पर अपग्रेड कर सकता है, +लेकिन यदि दुर्लभ रूप से शोषण हो तो कभी पता न चले। + +### क्वांटम कंप्यूटिंग समयरेखाएँ + +क्वांटम सफलताएँ अपेक्षा से बहुत बाद आ सकती हैं, +PQC की आवश्यकता देरी से; इसके विपरीत, गुप्त विकास (उदा. +सरकारों द्वारा) अचानक खतरे पैदा कर सकता है यदि ब्लॉकचेन समुदाय +तेज़ी से अपडेट न करे। + +### अन्य विचार + +सामान्य अपनाने की बाधाएँ, वित्त/ब्लॉकचेन में नियामक अनिश्चितता, +और क्रिप्टो पारिस्थितिकी तंत्र की अंतर्निहित अस्थिरता। + + + +
    + + + Shor, P. W. (1997). Polynomial-time algorithms for prime factorization and + discrete logarithms on a quantum computer. _SIAM Journal on Computing_, 26(5), + 1484–1509. https://doi.org/10.1137/S0097539795293172 + + + + Grover, L.K. (1996). A fast quantum mechanical algorithm for database search. + _Proceedings of the Twenty-Eight Annual ACM Symposium on Theory of Computing_, + 212-219. https://doi.org/10.1145/237814.237866 + + + + Chainalysis. (2024). _The Chainalysis 2024 Crypto Crime Report_. + https://www.chainalysis.com/blog/2024-crypto-crime-report-introduction/ + + + + National Institute of Standards and Technology. (2024). _FIPS 204: + Module-Lattice-Based Digital Signature Standard (ML- DSA)_. U.S. Department of + Commerce. https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf + + + + National Institute of Standards and Technology. (2024). _FIPS 203: + Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)_. U.S. + Department of Commerce. + https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf + + + + Häner, T., Jaques, S., Naehrig, M., Roetteler, M., & Soeken, M. (2020). + Improved quantum circuits for elliptic curve discrete logarithms. + _arXiv:2002.12480_. https://arxiv.org/abs/2002.12480 + + + + Gidney, C., & Ekerå, M. (2021). _How to factor 2048 bit RSA integers in 8 + hours using 20 million noisy qubits_. _arXiv:1905.09749_. + https://arxiv.org/abs/1905.09749 + + + + Aggarwal, D., et al. (2021). Assessment of Quantum Threat To Bitcoin and + Derived Cryptocurrencies. _ePrint IACR_. https://eprint.iacr.org/2021/967.pdf + + + + Roetteler, M., Naehrig, M., Svore, K. M., & Lauter, K. (2017). Quantum + resource estimates for computing elliptic curve discrete logarithms. + _arXiv:1706.06752_. https://arxiv.org/abs/1706.06752 + + + + Open Quantum Safe Project. (n.d.). ML-DSA | Open Quantum Safe. Retrieved + January 29, 2026, from + https://openquantumsafe.org/liboqs/algorithms/sig/ml-dsa.html + diff --git a/website/src/contents/whitepapers/id-ID/v0.3.3.mdx b/website/src/contents/whitepapers/id-ID/v0.3.3.mdx new file mode 100644 index 0000000..d07dacf --- /dev/null +++ b/website/src/contents/whitepapers/id-ID/v0.3.3.mdx @@ -0,0 +1,861 @@ +--- +title: "Quantus Network Whitepaper" +version: "0.3.3" +publishedDate: "2026-03-21" +updatedDate: "2026-03-21" +authors: ["Christopher Smith"] +changelog: + - "Revisi besar: Penafian hukum, Daftar isi, bab bernomor (01–09), sampul PDF, TOC; «References & Further Reading» mengganti bagian penutup." + - "Bab baru: Krisis migrasi (koordinasi, koin hilang, linimasa migrasi PQC)." + - "Pendahuluan dan bagian ancaman kuantum ditulis ulang: kerangka CRQC, empat kategori ancaman bernomor, kutipan dalam teks." + - "Arsitektur dan bagian teknis diperluas atau diperjelas (Foundation/Substrate, LibP2P, wormhole/Plonky2, konsensus/medan Goldilocks)." + - "Peta jalan: Bell Mainnet Q2 2026; Fermi Upgrade Q4 2026; Planck Beta menambah integrasi ZK." +pdfCover: true +# Astro `render().headings` tidak menyertakan `

    ` JSX dan ChapterHeading; slug jangkar sama dengan id `###` Markdown. +toc: + insertBefore: + ancaman-kuantum: + - slug: legal-disclaimer + text: Penafian hukum + - slug: contents + text: Daftar isi + - slug: chapter-01 + text: Pendahuluan + dasar-dasar-komputasi-kuantum: + - slug: chapter-02 + text: Ancaman Kuantum terhadap Blockchain + masalah-koordinasi: + - slug: chapter-03 + text: Krisis Migrasi + fondasi: + - slug: chapter-04 + text: Arsitektur Quantus Network + transaksi-reversibel: + - slug: chapter-05 + text: Pelestarian Kekayaan + hadiah-blok: + - slug: chapter-06 + text: Tokenomik dan Tata Kelola + masalah-implementasi: + - slug: chapter-07 + text: Peta jalan + - slug: chapter-08 + text: Risiko + insertAfter: + pertimbangan-lain: + - slug: chapter-09 + text: Referensi & Bacaan lanjutan +--- + +import CalloutV2 from "@/components/features/whitepaper/mdx/CalloutV2.astro"; +import Figure from "@/components/features/whitepaper/mdx/Figure.astro"; +import Grid from "@/components/features/whitepaper/mdx/Grid.astro"; +import Column from "@/components/features/whitepaper/mdx/Column.astro"; +import TimelineV2 from "@/components/features/whitepaper/mdx/TimelineV2.astro"; +import ResponsiveTableV2 from "@/components/features/whitepaper/mdx/ResponsiveTableV2.astro"; +import SiteSocials from "@/components/ui/SiteSocials.astro"; +import OrderedList from "@/components/features/whitepaper/mdx/OrderedList.astro"; +import Divider from "@/components/features/whitepaper/mdx/Divider.astro"; +import ChapterHeading from "@/components/features/whitepaper/mdx/ChapterHeading.astro"; +import Reference from "@/components/features/whitepaper/mdx/Reference.astro"; +import ReferenceMarker from "@/components/features/whitepaper/mdx/ReferenceMarker.astro"; + +

    + +_Whitepaper ini disediakan hanya untuk tujuan informasi dan +bukan merupakan penawaran untuk menjual, ajakan untuk membeli, +atau rekomendasi untuk sekuritas, investasi, atau produk keuangan +apa pun. Pembaca harus melakukan uji tuntas sendiri dan +berkonsultasi dengan profesional yang berkualifikasi sebelum membuat keputusan investasi +apa pun. Quantus Network tidak memberikan pernyataan atau jaminan +mengenai keakuratan atau kelengkapan informasi di sini._ + +

    + Daftar isi +

    + + + +
    + + + +### Ancaman kuantum + +Blockchain tradisional menghadapi ancaman eksistensial dari +komputer kuantum yang relevan secara kriptografis (CRQC). Fondasi +kriptografi blockchain bergantung pada kesulitan +masalah logaritma diskrit (DLP), dan algoritma kuantum, +terutama Shor, dapat menyelesaikan DLP secara eksponensial lebih cepat daripada +komputer klasik. Kerentanan ini dapat memungkinkan penyerang +kuantum untuk menurunkan kunci privat dari kunci publik, yang akan +memungkinkan mereka memalsukan transaksi dan mendekripsi data keuangan +yang sensitif. + +> tanpa peningkatan tahan kuantum yang proaktif, ekonomi kripto bernilai triliunan dolar +> berisiko devaluasi mendadak akibat serangan semacam itu. + +### Proposisi nilai unik + +Dinamai dari kata Latin untuk "berapa banyak", Quantus Network +menghadirkan uang privat yang skalabel dan aman secara kuantum. Quantus bukan +platform smart contract serba guna. Seperti restoran dengan beberapa +menu yang sangat disempurnakan, Quantus menyediakan: + +- Tanda tangan pasca-kuantum untuk semua transaksi +- Tanda tangan dan enkripsi Pasca-Kuantum (ML-DSA dan ML-KEM) untuk mengamankan koneksi peer +- Bukti tanpa pengetahuan (zero-knowledge) pasca-kuantum untuk penskalaan +- Akun Keamanan Tinggi untuk mencegah pencurian dan memungkinkan pemulihan dari kesalahan +- Frasa pemeriksaan yang mudah dibaca manusia untuk verifikasi alamat yang mudah + +Keputusan untuk fokus pada uang privat yang skalabel dan aman secara kuantum +berasal dari ancaman yang ditimbulkan CRQC terhadap industri dan ketidakmampuan Bitcoin +untuk mengatasi tantangan ini. + + + +### Dasar-dasar komputasi kuantum + +Komputer kuantum memanfaatkan prinsip seperti superposisi dan +keterikatan untuk melakukan komputasi yang sulit bagi +mesin klasik. Berbeda dengan bit klasik, yang bernilai 0 atau 1, +bit kuantum (qubit) dapat berada dalam banyak keadaan secara bersamaan, +memungkinkan paralelisme eksponensial untuk masalah tertentu. Kemampuan +ini menimbulkan risiko eksistensial terhadap sistem kriptografi yang mendasari +keuangan blockchain, karena algoritma yang dikembangkan untuk +perangkat keras kuantum merusak asumsi keamanan dari sebagian besar +kriptografi kunci publik. + +**Algoritma Shor**, diperkenalkan pada 1994 oleh Peter Shor, memberikan +metode waktu polinomial untuk memfaktorkan bilangan bulat besar dan menyelesaikan +masalah logaritma diskrit pada komputer kuantum. Algoritma ini mengeksploitasi +Quantum Fourier Transform (QFT) untuk menemukan periode suatu fungsi, +memungkinkan pembalikan efisien dari fungsi trapdoor yang mendasari +skema seperti RSA atau kriptografi kurva eliptik (ECC). Untuk +keuangan blockchain, ini berarti penyerang dengan komputer kuantum yang cukup +kuat (diperkirakan ~2.000 qubit logis ) +dapat menurunkan kunci privat dari kunci publik dalam waktu polinomial O(n³) — percepatan ekstrem +yang membuat sistem rentan usang dalam semalam. + +**Algoritma Grover**, diusulkan oleh Lov Grover pada 1996, menawarkan +percepatan kuadratik untuk masalah pencarian tak terstruktur, mengurangi +waktu pencarian dari O(n) menjadi O(√n) operasi. Meskipun tidak se +dahsyat Shor untuk kriptografi asimetris, Grover +mempengaruhi primitif simetris seperti fungsi hash dan enkripsi AES, +secara efektif membagi dua tingkat keamanan (misalnya kunci 256-bit +berperilaku seperti 128 bit terhadap serangan kuantum). Serangan ini +dimitigasi dengan menggandakan bit keamanan, bukan mengubah +skema kriptografi. Selain itu, percepatan kuadratik Grover +tidak praktis karena persyaratan qubit dan gerbang yang tinggi, +membutuhkan miliaran operasi berurutan dengan paralelisasi terbatas, +sehingga tidak layak untuk pembalikan dunia nyata bahkan pada +perangkat keras masa depan. + +### Empat kategori ancaman + +#### 01 - Memalsukan tanda tangan digital + +Algoritma Shor secara langsung mengancam tanda tangan berbasis ECC yang digunakan di +sebagian besar blockchain (misalnya kurva secp256k1 Bitcoin), memungkinkan +penyerang menyamar sebagai pengguna dan mengotorisasi transaksi +palsu. Kemampuan seperti itu akan merupakan kegagalan kritis dari +fitur paling dasar sebuah blockchain. + +#### 02 - Memalsukan bukti palsu dalam sistem zero-knowledge + +Banyak bukti zero-knowledge, seperti dalam zk-SNARKs untuk +keuangan berfokus privasi, bergantung pada kesulitan logaritma diskrit melalui +pasangan kurva eliptik untuk komitmen. Shor dapat memungkinkan +pembuatan bukti tidak valid yang tampak valid, yang dapat memungkinkan penyerang +mencetak koin baru atau memalsukan keadaan Layer-2 (L2). + +#### 03 - Mendekripsi informasi rahasia + +Serangan kuantum dapat mengekspos data terenkripsi yang dilindungi oleh +skema kunci publik rentan dalam protokol privasi seperti Zcash +atau Monero. Serangan ini juga dapat mendekripsi komunikasi p2p dalam protokol +keuangan, mengungkap detail kekayaan sensitif dan memungkinkan pencurian +bertarget. + +#### 04 - Membalikkan fungsi hash + +Algoritma Grover dapat mempercepat serangan preimage pada hash +seperti SHA-256, digunakan untuk proof-of-work dan pembuatan alamat, tetapi +ini adalah ancaman yang paling tidak mengkhawatirkan. Banyak skema +kriptografi pasca-kuantum menggabungkan konstruksi berbasis hash karena +hash dianggap cukup aman dengan digest yang cukup besar. + +### Tantangan penskalaan dalam kriptografi pasca-kuantum + +Meskipun kriptografi pasca-kuantum (PQC) menawarkan perlindungan penting +terhadap ancaman kuantum, PQC memperkenalkan hambatan penskalaan signifikan +karena desain inheren algoritma ini. +Berbeda dengan skema kurva eliptik, yang mengandalkan struktur matematika ringkas, +primitif PQC memerlukan parameter lebih besar untuk mempertahankan +keamanan terhadap penyerang klasik dan kuantum. Hal ini +menghasilkan kunci publik, kunci privat, dan tanda tangan yang jauh lebih besar, +sering berorde magnitudo. Tabel berikut mengilustrasikan ukuran tipikal untuk ML-DSA pada tingkat keamanan pasca-kuantum 128-bit +dibandingkan rekan klasik seperti ECDSA 256-bit: + + + +Ukuran pada tingkat keamanan pasca-kuantum 128-bit. Sumber: Open +Quantum Safe Project + +Seperti ditunjukkan, tanda tangan ML-DSA dapat lebih dari 70 kali lebih besar daripada +setara ECDSA, dan kunci publik lebih dari 80 kali lebih besar. +Keluarga PQC lain memperparah hal ini: skema berbasis hash seperti +SPHINCS+ dapat menghasilkan tanda tangan hingga 41 KB, sementara varian lattice yang dioptimalkan ukuran +seperti FALCON masih melebihi ukuran klasik +dengan kelipatan signifikan. + +Dalam konteks blockchain, ukuran yang membengkak ini berlipat menjadi +masalah penskalaan sistemik. Tanda tangan yang lebih besar membengkak +transaksi individu, mengurangi transaksi per detik (TPS) karena blok terisi +lebih cepat dan memerlukan lebih banyak waktu untuk validasi. Ini juga membebani komunikasi peer- +to-peer (P2P), meningkatkan kebutuhan bandwidth dan +penundaan propagasi, yang dapat meningkatkan risiko fork jaringan atau +blok yatim dalam mekanisme konsensus seperti proof-of-work. +Persyaratan penyimpanan juga terpengaruh, menyebabkan biaya operasi node lebih tinggi dan hambatan partisipasi, terutama bagi +pengguna atau validator dengan sumber daya terbatas. + + + Tantangan penskalaan ini harus diatasi oleh semua blockchain di masa depan. + Bitcoin, misalnya, akan memiliki jauh kurang dari 1 TPS jika ukuran blok + maksimum tidak ditingkatkan. + + + + +### Masalah koordinasi + +Budaya konservatif Bitcoin menolak perubahan protokol. Peningkatan PQC +mana pun akan memerlukan konsensus tentang isu kontroversial seperti +timeline migrasi, potensi penyitaan koin, dan peningkatan ukuran blok. +Bahkan jika komunitas setuju, setiap pengguna +harus memigrasikan koin mereka ke alamat aman kuantum baru. +Migrasi memerlukan tindakan dari setiap pemegang kripto, +banyak di antaranya kehilangan akses ke dompet atau tidak menyadari +ancaman. + +Isu ini ada di setiap blockchain publik, tetapi sangat menantang bagi Bitcoin karena kurangnya kepemimpinan yang jelas dan +filsafat pengerasan teknis. + +### Masalah koin yang hilang + +Perkiraan $250 miliar hingga $500 miliar nilai Bitcoin +tidak dapat diakses secara permanen karena kunci yang hilang, pemegang yang meninggal, atau +dompet yang terlupakan. [3] Koin ini tidak dapat dimigrasikan dan berfungsi +sebagai hadiah publik untuk membuat komputer kuantum yang relevan secara kriptografis (CRQC). Penyerang kuantum akan menurunkan kunci privat +dari kunci publik yang tidak dimigrasikan dan kemungkinan membanjiri miliaran +dolar BTC ke pasar. + +> satu-satunya solusi teknis memerlukan tenggat keras +> yang membekukan koin yang tidak dimigrasikan — sebuah +> kemustahilan politik. + +Tanpa tenggat seperti itu, hasilnya adalah koin yang tidak dimigrasikan +dicuri dan dijual, menghancurkan pasar dan merusak +kepercayaan pada jaringan. + +### Masalah timeline migrasi + +Tanda tangan pasca-kuantum 20x–80x lebih besar daripada tanda tangan Bitcoin saat ini. +Tanpa perubahan arsitektur mendasar, throughput Bitcoin +akan runtuh menjadi sebagian kecil dari kapasitas terbatasnya. + +Dengan asumsi Bitcoin mengatasi tantangan politik dan teknis, +migrasi itu sendiri akan memakan waktu berbulan-bulan atau bertahun-tahun. Setiap pemegang harus +mengirim setidaknya satu transaksi untuk memindahkan dana ke alamat aman kuantum. +Banyak yang akan mengirim transaksi uji terlebih dahulu. Dengan tanda tangan PQC yang membengkak yang mencekik throughput, jaringan menghadapi antrian yang berlangsung +berbulan-bulan atau bertahun-tahun sementara koin rentan kuantum tetap terpapar. + + + Tantangan yang bertumpuk ini membuat retrofit keamanan kuantum ke chain yang + ada sangat sulit. Quantus Network menghindari ini dengan membangun keamanan + kuantum ke dalam chain sejak hari pertama. + + + + +### Fondasi + +Quantus Network dibangun di atas Substrate, SDK blockchain +yang dikembangkan oleh Parity Technologies, tim di balik Ethereum dan +Polkadot. Substrate sangat modular, memungkinkan penggantian komponen dengan mudah sehingga kami dapat fokus pada apa yang membuat Quantus unik. + +Quantus meningkatkan Substrate dengan: + +- Menambahkan dukungan untuk skema tanda tangan pasca-kuantum +- Meningkatkan keamanan jaringan p2p menjadi pasca-kuantum +- Menambahkan reversibilitas transaksi yang dikontrol pengguna +- Membuat database ramah zk dengan menyelaraskan semua tipe data ke + batas elemen lapangan + +### Primitif kriptografi pasca-kuantum + +Quantus Network menggunakan PQC yang distandarisasi NIST untuk memastikan +keamanan transaksi dan komunikasi jaringan terhadap +ancaman kuantum. Inti integritas transaksi adalah **ML-DSA** +(Module-Lattice-based Digital Signature Algorithm, sebelumnya dikenal sebagai +CRYSTALS-Dilithium), skema tanda tangan berbasis lattice yang dipilih karena keseimbangan keamanan, efisiensi, dan kemudahan +implementasi. ML-DSA memanfaatkan kesulitan masalah seperti +Learning With Errors (LWE) dan Short Integer Solution (SIS) pada +module lattice, memberikan resistensi kuat terhadap serangan klasik dan +kuantum, termasuk dari algoritma Shor. + +Untuk tanda tangan transaksi, Quantus mengintegrasikan **ML-DSA-87**, set parameter +dengan tingkat keamanan tertinggi (NIST Security +Level 5, setara 256-bit klasik dan 128-bit kuantum) +untuk melindungi dari kemungkinan terobosan kriptanalisis lattice. +Pilihan ini memprioritaskan kehati-hatian, karena kriptografi lattice relatif baru dan kurang teruji di medan perang dibanding skema klasik. +Parameter yang lebih besar memitigasi risiko dari kemajuan potensial +dalam kriptanalisis lattice, yang masih akan meninggalkan ukuran kunci +lebih kecil sebagai target yang lebih lunak. + +#### Alternatif yang dipertimbangkan + +ML-DSA dipilih dibanding alternatif seperti FN-DSA (Falcon) karena +kompleksitas implementasi FN-DSA yang lebih besar (mis. memerlukan +operasi floating-point, yang tidak ramah blockchain), tidak adanya +generasi kunci deterministik dalam spesifikasinya, dan statusnya yang belum +final pada saat pengembangan. + +Opsi berbasis hash seperti SLH-DSA tidak dipilih karena +ukuran tanda tangan yang bahkan lebih besar (melebihi 17 KB). Crypto-agility +(kemampuan menukar skema tanda tangan berbeda) sudah tertanam dalam +Substrate, sehingga relatif mudah menambahkan alternatif ini di +tanggal mendatang jika diperlukan. + +Meskipun ML-DSA-87 menghasilkan kunci dan tanda tangan lebih besar, ini +dapat dikelola di jaringan tahap awal Quantus, di mana penyimpanan belum +menjadi bottleneck, dan optimisasi seperti alamat wormhole melalui +bukti zero-knowledge akan mengatasi penskalaan. + +Untuk detail teknis implementasi lihat [QIP-0006](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0006.md). + +### LibP2P - Jaringan aman kuantum + +Quantus Network mengamankan komunikasi node peer-to-peer (P2P) +menggunakan kombinasi ML-DSA untuk autentikasi +dan **ML-KEM** (Module-Lattice-based Key Encapsulation +Mechanism, sebelumnya CRYSTALS-Kyber) untuk enkripsi. Integrasi ini memperluas PQC ke stack jaringan libp2p, memodifikasi +komponen inti untuk resistensi kuantum: menggunakan tanda tangan ML-DSA-87 +untuk identitas peer dan ML-KEM-768 untuk keamanan transport +(memperpanjang handshake Noise dengan pesan KEM tambahan +untuk rahasia bersama tahan kuantum). + +Lapisan P2P sering diabaikan dalam analisis keamanan kuantum. +Autentikasi peer penting, tetapi yang terburuk yang dapat dilakukan penyerang +di level peer adalah menyamar sebagai node dan mengirim pesan +tidak valid, yang dapat mengakibatkan penolakan layanan. Serangan ini sudah +dimitigasi oleh fakta bahwa node umumnya tidak dipercaya dalam +model blockchain dan node dapat dengan mudah mengganti kunci jika +serangan terdeteksi. Demikian pula, mendekripsi komunikasi P2P +memberikan manfaat penyerang terbatas (mis. melacak jalur transaksi, +dimitigasi oleh proxy atau Tor), dan sebagian besar data menjadi publik di +chain. + +Namun, mengamankan lapisan P2P secara kuantum melindungi dari +penyadapan, serangan man-in-the-middle, dan dekripsi +kuantum, memastikan gossip node, propagasi blok, dan +interaksi jaringan lainnya tetap rahasia dan bebas gangguan +untuk masa mendatang. + +Untuk detail teknis implementasi lihat [QIP-0004](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0004.md). + +### Penskalaan PQC - alamat wormhole + +Untuk mengatasi tantangan penskalaan yang melekat dalam kriptografi +pasca-kuantum, Quantus Network memperkenalkan skema tanda tangan pasca-kuantum agregatif inovatif bernama **"Wormhole Addresses"**. +Sistem ini memanfaatkan bukti zero-knowledge (ZKP) +yang dihasilkan melalui sistem pembuatan bukti Plonky2 (pada dasarnya STARKs) untuk +memindahkan verifikasi saldo off-chain, memungkinkan chain memverifikasi +satu bukti ringkas tanpa memproses tanda tangan individu. +Wormhole Addresses memungkinkan verifikasi sejumlah besar +transaksi dengan satu bukti, dengan input publik (mis. nullifier, +akar penyimpanan, alamat keluar, dan jumlah) menjadi faktor pembatas utama. +Ini mengurangi kebutuhan penyimpanan per transaksi yang diamortisasi +menjadi sekitar 256 byte tambahan per transaksi, +jauh lebih kecil daripada skema tanda tangan PQC yang diketahui. + +Keamanan kuantum skema berasal dari penggunaan fungsi hash aman +**Poseidon2** untuk komitmen melalui FRI (Fast +Reed-Solomon Interactive Oracle Proofs), bukan pasangan kurva eliptik +rentan kuantum yang umum digunakan dalam SNARK. + +Selain itu rahasia autentikasi disembunyikan di balik +Poseidon2. Karena fungsi hash aman hanya melemah secara kuadratik +oleh algoritma Grover, bukan rusak, bukti preimage hash +dapat berfungsi sebagai tanda tangan pasca-kuantum ringan dalam konteks ZK, +mirip skema berbasis hash seperti SPHINCS+. + +#### Alur klien / prover + +Pengguna menghasilkan alamat yang terbukti tidak dapat dibelanjakan dengan menggandakan hash garam +yang digabungkan dengan rahasia: + +``` +H(H(salt|secret)) +``` + +Konstruksi ini mencegah positif palsu (mis. mengira kunci publik hash tunggal +sebagai alamat yang tidak dapat dibelanjakan) karena di Substrate +(dan umumnya) alamat blockchain adalah hash tunggal dari +kunci publik, yang diturunkan dari kunci privat melalui operasi aljabar +tertentu, bukan melalui hash aman. Keamanan konstruksi +karenanya berkurang menjadi menemukan preimage-dari-preimage dari +hash aman. Token yang dikirim ke alamat ini secara efektif dibakar. +Tidak dapat dibelanjakan karena tidak ada kunci privat untuk alamat +yang menerimanya. Koin ini karena itu dapat dicetak ulang +tanpa membengkak pasokan. + +Untuk setiap transfer, objek penyimpanan TransferProof dibuat, +berisi detail seperti penghitungan transfer global unik. Dompet pengguna +menghasilkan bukti penyimpanan Merkle-Patricia-Trie (MPT) dari +akar penyimpanan header blok terkini ke daun untuk TransferProof ini. +Nullifier dihitung untuk mencegah double-spend: + +``` +H(H(salt | secret | global_transfer_count)) +``` + +#### Alur agregator + +Pihak mana pun (klien, penambang, atau pihak ketiga) dapat mengagregasi banyak +bukti menggunakan rekursi Plonky2, membentuk pohon bukti di mana +setiap bukti induk adalah verifikasi bukti anak, dengan input publik anak +diagregasi: + +- Nullifier lewat tanpa berubah +- Alamat keluar dideduplikasi +- Hash blok dibuktikan terhubung lalu semua kecuali yang terbaru dibuang +- Jumlah untuk alamat keluar duplikat dijumlahkan + +#### Alur chain / verifikator + +Jaringan memverifikasi bukti agregat dengan memeriksa: hash blok +ada di chain dan baru-baru ini, keunikan nullifier (untuk mencegah double- +spend), dan validitas bukti. Sirkuit ZK menegakkan kebenaran bukti penyimpanan, +akurasi komputasi nullifier, alamat +tidak dapat dibelanjakan, kecocokan saldo antara input dan output, dan +penautan header blok. + +#### Mengapa Plonky2 + +- Sudah diaudit +- Pasca-kuantum +- Tanpa trusted setup +- Pembuatan/verifikasi efisien +- Agregasi bukti mulus +- Implementasi asli Rust +- Kompatibel dengan lingkungan no-std Substrate + + + Bukti rekursif selesai dalam 170 milidetik dengan ukuran ringkas (100 KB per + bukti agregat). Dalam kasus optimal dengan blok 5 MB dan semua transaksi + menuju output yang sama, Wormhole Addresses dapat memuat ~153.000 transaksi + dalam satu blok (4,9 MB / 32 byte per nullifier) — peningkatan 223x + dibandingkan ~685 transaksi ML-DSA mentah (5 MB / 7,3 KB masing-masing). + + +#### Catatan keamanan + +Risiko potensial termasuk bug inflasi dari implementasi sirkuit/verifikasi +yang cacat, meskipun ini akan terdeteksi secara ekonomi jika +koin yang dicetak ulang melebihi saldo alamat kirim nol. Pengguna +secara opsional dapat membuktikan alamat adalah wormhole dengan mempublikasikan +hash pertama tanpa mengungkap rahasia. Transaksi verifikasi tidak +ditandatangani, sehingga penolakan layanan melalui transaksi gagal perlu +dimitigasi non-keuangan. Perhitungan pasokan token +terjaga, karena cetak ulang muncul sebagai koin baru tetapi mempertahankan +jaminan pasokan maksimum melalui pembakaran. + +Untuk detail teknis lebih lanjut tentang implementasi lihat [QIP-0005](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0005.md). + +### Mekanisme konsensus + +Quantus Network menggunakan algoritma konsensus Proof-of-Work (PoW) +yang mempertahankan sifat menguntungkan konsensus Bitcoin +sementara meningkatkan kompatibilitas dengan sistem bukti ZK dengan +mengganti SHA-256 dengan **Poseidon2**. + +Penting, perubahan ini tidak dilakukan untuk keamanan kuantum. +Fungsi hash kriptografis seperti SHA-256 dilemahkan tetapi tidak +dimusnahkan oleh algoritma kuantum, terutama Grover. Beberapa skema +tanda tangan pasca-kuantum menggunakan hash aman sebagai blok bangunan +karena alasan ini. + +Poseidon2 adalah penyempurnaan fungsi hash Poseidon. Membuat +SNARK atau STARK untuk komputasi yang melibatkan hash tradisional +seperti SHA-256 sering memerlukan hampir 100x lebih banyak +gerbang dibandingkan menggunakan Poseidon, yang sepenuhnya mengandalkan +fungsi aljabar atas elemen lapangan, bukan operasi bit. + +Kami menggunakan **lapangan Goldilocks** untuk Poseidon2 dan Plonky2. Urutan +lapangan Goldilocks muat dalam bilangan bulat tak bertanda 64-bit, yang +meningkatkan efisiensi tanpa mengorbankan soundness. + + + +Ada banyak risiko dalam mengelola kunci kripto. Sebagian besar +dapat dihindari. + +### Transaksi reversibel + +Quantus Network menawarkan transaksi reversibel yang dapat dikonfigurasi pengguna. +Pengirim menetapkan jendela waktu di mana mereka dapat membatalkan transfer +keluar. Ini mencegah pencurian dan memperbaiki kesalahan tanpa mengorbankan +finalitas. Sistem menggunakan pallet Substrate "scheduler" yang dimodifikasi +dengan timestamp. Dompet menampilkan hitung mundur untuk pengirim +(dengan tombol batal) dan penerima. + +Transaksi reversibel memungkinkan protokol keamanan baru sambil +mempertahankan desentralisasi melalui penegakan on-chain. + +Untuk detail teknis lebih lanjut lihat [QIP-0009](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0009.md). + +### Frasa pemeriksaan + +Quantus Network memperkenalkan "check-phrases," checksum yang dapat dibaca manusia dan aman secara kriptografis +untuk alamat blockchain. Alamat di-hash untuk menghasilkan urutan kata pendek yang mudah diingat +dari daftar mnemonik BIP-39. Check-phrases melindungi +dari typo, manipulasi, dan serangan racun alamat. Fungsi derivasi kunci 50.000 iterasi +membuat serangan rainbow table mahal. Untuk transaksi besar, pengguna tetap harus memverifikasi setiap +karakter alamat. + +Untuk detail teknis lihat [QIP-0008](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0008.md). + +### Akun keamanan tinggi + +Akun mana pun dapat ditingkatkan menjadi "akun keamanan tinggi" dengan +periode pembalikan wajib pada semua transfer keluar. **Wali** yang ditunjuk +(dompet perangkat keras, multisig, atau pihak ketiga tepercaya) dapat +membatalkan transaksi mencurigakan selama periode pembalikan, mengirim +dana ke wali alih-alih pengirim atau penerima. Fitur opt-in ini permanen setelah diaktifkan, mencegah pencuri +menonaktifkannya. + +Wali dapat dirantai: wali akun keamanan tinggi dapat +sendiri menjadi akun keamanan tinggi dengan walinya sendiri. Ini menciptakan +hierarki yang dapat dikomposisikan di mana setiap wali memiliki izin superior +terhadap akun yang dilindungi. Desain ini memberi pengguna waktu +untuk mendeteksi dan merespons aktivitas tidak sah tanpa +mengorbankan finalitas untuk transfer sah. + +Untuk detail teknis lebih lanjut lihat [QIP-0011](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0011.md). + +### Pemulihan kunci + +Banyak kekayaan kripto ikut ke kubur bersama pemiliknya. +Quantus Network menawarkan cara sederhana untuk menentukan alamat pemulihan +yang dapat menarik dana Anda kapan saja, tunduk pada penundaan tetap. Selama +waktu ini, pemilik dapat menolak pemulihan jika mereka memiliki akses ke +kunci. Fitur ini memungkinkan survivorship: pengguna memiliki wasiat on-chain +tanpa pengadilan atau perwalian. + +### HD-Lattice + +Dompet Hierarchical Deterministic (HD) adalah standar industri +untuk blockchain, memungkinkan pengguna mencadangkan satu frasa benih untuk semua +kunci, meningkatkan keamanan dan kenyamanan dibanding cadangan manual per +tindakan. Mengadaptasi ini ke skema lattice seperti Dilithium melibatkan dua +tantangan: + +- Keluaran HMAC-SHA512 tidak dapat langsung membentuk kunci privat lattice, + yang merupakan polinomial yang disampel dari ring dengan properti + tertentu. +- Derivasi kunci non-hardened mengandalkan penjumlahan kurva eliptik, + yang tidak ada pada lattice (kunci publik tidak tertutup di bawah operasi aljabar + apa pun). + +Quantus Network mengatasi masalah pertama dengan menggunakan keluaran +HMAC sebagai entropi untuk membangun kunci privat secara deterministik, +bukan sebagai kunci privat itu sendiri. Masalah kedua kurang kritis dan +tetap pertanyaan riset terbuka apakah kriptografi lattice +dapat diadaptasi untuk mengatasinya. + +Untuk detail teknis lebih lanjut lihat [QIP-0002](https://github.com/Quantus-Network/improvement-proposals/tree/main/qip-0002). + + + +Quantus Network berada di lingkungan yang berubah, dan kami tidak dapat +menganggap semuanya benar pada percobaan pertama. Oleh karena itu, +kami memilih titik awal sederhana dan memungkinkan +sistem tata kelola membuat perubahan seiring informasi baru +diperoleh. Desain ini menjadikan blockchain entitas hidup yang dapat +beradaptasi pada lingkungannya. Khususnya, proses tata kelola Substrate +memungkinkan perubahan mendalam pada chain dengan koordinasi minimal +antara berbagai pengelola node. + +### Hadiah blok + +Quantus Network menggunakan model tokenomik lugas yang meniru +Bitcoin. Ada pasokan maksimum **21.000.000 koin** dan heuristik sederhana +menentukan hadiah setiap blok: + +``` +block_reward = (max_supply - current_supply) / constant +``` + +Heuristik ini membentuk kurva peluruhan eksponensial halus karena +block_reward berkontribusi pada current_supply yang mengurangi +block_reward yang dihitung pada blok berikutnya. Pembakaran dari biaya atau +lainnya mengurangi current_supply dan pada dasarnya menjadi bagian dari +anggaran hadiah blok. Konstanta dipilih sehingga, tanpa +pembakaran apa pun, 99% koin akan dikeluarkan dalam sekitar 30 +tahun. + +### Alokasi investor + +Quantus Network dibangun dengan bantuan investor yang mengambil +risiko besar dalam pendanaan. Investor privat tunduk pada jadwal vesting 4 tahun, +seperti tim. Investor penjualan publik akan sepenuhnya likuid pada hari pertama. Dana yang terkumpul dalam penjualan publik akan +dicocokkan dengan token dan digunakan untuk likuiditas (DEX, CEX, dan market +maker). Alokasi investor ini serta likuiditas akan menjadi +satu-satunya "pre-mine". Semua token lain harus ditambang ke dalam +keberadaan. + +Jika kurang dari maksimum 10% terjual selama +penjualan publik, akan ada pengurangan proporsional pada token +likuiditas dan sisanya akan dikeluarkan ke penambang melalui hadiah blok. + +### Alokasi perusahaan + +Untuk mengompensasi tim karena mengambil risiko membangun teknologi baru +tanpa jaminan kesuksesan, sebagian hadiah blok dikirim ke +perusahaan selama sekitar empat tahun. Ini memberikan jadwal vesting de facto sekitar **15% dari total pasokan** ke perusahaan. + +Setelah itu, bagian perusahaan dari hadiah blok dapat +dimatikan, disesuaikan atau dialihkan sesuai suara pemegang token. + +### Biaya transaksi + + + +### Peningkatan tanpa fork + +Quantus Network mendukung peningkatan "tanpa fork" melalui +peningkatan runtime Substrate, memungkinkan logika inti blockchain +("runtime") berkembang tanpa hard fork yang dapat mengganggu +jaringan atau memecah komunitas. Ini dicapai melalui referendum tata kelola on-chain, di mana proposal yang disetujui memicu swap runtime +— pada dasarnya mengganti blob kode WASM yang ada dengan yang +baru dalam satu blok, memastikan kontinuitas status dan +operasi. Jalur peningkatan ini meminimalkan downtime dan risiko, +memberdayakan komunitas untuk menyempurnakan protokol secara iteratif seiring +penggunaan dunia nyata mengungkap perbaikan potensial. + +Seiring komunitas memperoleh kepercayaan pada sistem dari waktu ke waktu, +kekuatan untuk mengubah runtime akan dikurangi secara signifikan untuk membatasi +permukaan serangan, jika aktor jahat memperoleh kendali atas +proses peningkatan. + +### Sistem tata kelola + +Quantus Network mewarisi kerangka tata kelola dari +sistem OpenGov Polkadot melalui Substrate. Pemegang token +berpartisipasi melalui **conviction voting**, di mana mereka setuju mengunci +aset untuk periode bervariasi untuk memperkuat bobot suara. Penguatan ini dapat berkisar dari 1x (tanpa kunci) hingga 6x (kunci maksimum). +Desain ini mendorong keselarasan jangka panjang dengan mengikat pengaruh pada +komitmen. + +Proposal dikategorikan ke beberapa trek voting yang disebut +"origins". Setiap origin memiliki parameter yang disesuaikan seperti ambang +persetujuan (mis. supermayoritas untuk perubahan berdampak tinggi), deposit minimum untuk mencegah spam, periode persiapan/pelaksanaan, dan +timeline keputusan untuk mencegah kebuntuan. Desain multi-trek ini +memungkinkan pemrosesan paralel referendum beragam, dari pengeluaran treasury rutin +hingga peningkatan runtime kritis. + +**Technical Collective** adalah kelompok kurasi ahli teknis +yang bertindak sebagai badan khusus untuk mengusulkan, meninjau, atau mendaftar urusan teknis mendesak, +mempercepatnya melalui trek khusus sambil +mempertahankan pengawasan komunitas. + +Quantus mengadopsi sistem ini tanpa modifikasi tetapi memulai dengan +setup minimalis untuk menghindari kompleksitas di tahap awal. Awalnya, +hanya trek Technical Collective yang aktif, yang akan digunakan untuk +keputusan mengikat berprivilegi tinggi seperti peningkatan protokol atau +penyesuaian parameter. + +Nanti, Quantus dapat menambahkan trek suara komunitas non-mengikat untuk +mengukur sentimen pada topik tidak dapat ditegakkan, seperti saran fitur +atau polling ekosistem. Sistem ini menjadi mengikat +ketika perusahaan menyerahkan jaringan ke DAO. Pendekatan bertahap +ini memungkinkan jaringan berkembang secara organik melalui suara tata kelola mendatang +tanpa membebani pengguna dengan kompleksitas yang tidak perlu +di awal. + + + +Peta jalan saat ini hingga 2026, dapat berubah. + + + + + + + + + + + + + + + +
    + + + +Membangun Quantus Network disertai risiko inheren. + +### Masalah implementasi + +Kekacauan logika perangkat lunak dapat menyebabkan kegagalan serius bahkan pada sistem yang paling baik +dirancang. + +### Masalah pemilihan algoritma NIST + +Kekacauan atau pintu belakang potensial dalam standar pasca-kuantum terpilih +(mis. ML-DSA, ML-KEM) yang dapat muncul pasca-standardisasi. Dalam +kasus terburuk, kekacauan tersebut memungkinkan penyerang memalsukan +tanda tangan dengan menurunkan kunci privat dari publik, mewakili +mode kegagalan katastrofik chain. Jika kekacauan tersebut diumumkan, +Quantus Network dapat ditingkatkan ke algoritma baru, +tetapi jika dieksploitasi jarang mungkin tidak pernah +terdeteksi. + +### Timeline komputasi kuantum + +Terobosan kuantum mungkin datang jauh lebih lambat dari perkiraan, +menunda kebutuhan PQC; sebaliknya, pengembangan rahasia (mis. +oleh pemerintah) dapat menyebabkan ancaman mendadak jika komunitas blockchain +gagal memperbarui dengan cepat. + +### Pertimbangan lain + +Hambatan adopsi umum, ketidakpastian regulasi dalam +keuangan/blockchain, dan volatilitas inheren ekosistem kripto. + + + +
    + + + Shor, P. W. (1997). Polynomial-time algorithms for prime factorization and + discrete logarithms on a quantum computer. _SIAM Journal on Computing_, 26(5), + 1484–1509. https://doi.org/10.1137/S0097539795293172 + + + + Grover, L.K. (1996). A fast quantum mechanical algorithm for database search. + _Proceedings of the Twenty-Eight Annual ACM Symposium on Theory of Computing_, + 212-219. https://doi.org/10.1145/237814.237866 + + + + Chainalysis. (2024). _The Chainalysis 2024 Crypto Crime Report_. + https://www.chainalysis.com/blog/2024-crypto-crime-report-introduction/ + + + + National Institute of Standards and Technology. (2024). _FIPS 204: + Module-Lattice-Based Digital Signature Standard (ML- DSA)_. U.S. Department of + Commerce. https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf + + + + National Institute of Standards and Technology. (2024). _FIPS 203: + Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)_. U.S. + Department of Commerce. + https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf + + + + Häner, T., Jaques, S., Naehrig, M., Roetteler, M., & Soeken, M. (2020). + Improved quantum circuits for elliptic curve discrete logarithms. + _arXiv:2002.12480_. https://arxiv.org/abs/2002.12480 + + + + Gidney, C., & Ekerå, M. (2021). _How to factor 2048 bit RSA integers in 8 + hours using 20 million noisy qubits_. _arXiv:1905.09749_. + https://arxiv.org/abs/1905.09749 + + + + Aggarwal, D., et al. (2021). Assessment of Quantum Threat To Bitcoin and + Derived Cryptocurrencies. _ePrint IACR_. https://eprint.iacr.org/2021/967.pdf + + + + Roetteler, M., Naehrig, M., Svore, K. M., & Lauter, K. (2017). Quantum + resource estimates for computing elliptic curve discrete logarithms. + _arXiv:1706.06752_. https://arxiv.org/abs/1706.06752 + + + + Open Quantum Safe Project. (n.d.). ML-DSA | Open Quantum Safe. Retrieved + January 29, 2026, from + https://openquantumsafe.org/liboqs/algorithms/sig/ml-dsa.html + diff --git a/website/src/contents/whitepapers/ja-JP/v0.3.3.mdx b/website/src/contents/whitepapers/ja-JP/v0.3.3.mdx new file mode 100644 index 0000000..e0079e1 --- /dev/null +++ b/website/src/contents/whitepapers/ja-JP/v0.3.3.mdx @@ -0,0 +1,530 @@ +--- +title: "Quantus Network Whitepaper" +version: "0.3.3" +publishedDate: "2026-03-21" +updatedDate: "2026-03-21" +authors: ["Christopher Smith"] +changelog: + - "大幅改訂:法的免責事項、目次、章番号(01–09)、PDF表紙、TOC;末尾は「参考文献・関連資料」に変更。" + - "新章:移行の危機(調整問題、紛失コイン、PQC移行のタイムライン)。" + - "序論と量子脅威の章を再執筆:CRQCの枠組み、4つの脅威カテゴリ、本文中の引用。" + - "アーキテクチャと技術節を拡充・明確化(Foundation/Substrate、LibP2P、wormhole/Plonky2、コンセンサス/Goldilocks体)。" + - "ロードマップ:Bellメインネット 2026年Q2;Fermiアップグレード 2026年Q4;Planck BetaにZK統合を追加。" +pdfCover: true +# Astro の `render().headings` は JSX の `

    ` と ChapterHeading を含みません。アンカー slug は Markdown の `###` の id と一致します。 +toc: + insertBefore: + 量子の脅威: + - slug: legal-disclaimer + text: 免責事項 + - slug: contents + text: 目次 + - slug: chapter-01 + text: はじめに + 量子計算の基礎: + - slug: chapter-02 + text: ブロックチェーンに対する量子の脅威 + 調整問題: + - slug: chapter-03 + text: 移行の危機 + 基礎: + - slug: chapter-04 + text: Quantus Networkのアーキテクチャ + 可逆トランザクション: + - slug: chapter-05 + text: 資産の保全 + ブロック報酬: + - slug: chapter-06 + text: トークノミクスとガバナンス + 実装上の問題: + - slug: chapter-07 + text: ロードマップ + - slug: chapter-08 + text: リスク + insertAfter: + その他の考慮: + - slug: chapter-09 + text: 参考文献と関連資料 +--- + +import CalloutV2 from "@/components/features/whitepaper/mdx/CalloutV2.astro"; +import Figure from "@/components/features/whitepaper/mdx/Figure.astro"; +import Grid from "@/components/features/whitepaper/mdx/Grid.astro"; +import Column from "@/components/features/whitepaper/mdx/Column.astro"; +import TimelineV2 from "@/components/features/whitepaper/mdx/TimelineV2.astro"; +import ResponsiveTableV2 from "@/components/features/whitepaper/mdx/ResponsiveTableV2.astro"; +import SiteSocials from "@/components/ui/SiteSocials.astro"; +import OrderedList from "@/components/features/whitepaper/mdx/OrderedList.astro"; +import Divider from "@/components/features/whitepaper/mdx/Divider.astro"; +import ChapterHeading from "@/components/features/whitepaper/mdx/ChapterHeading.astro"; +import Reference from "@/components/features/whitepaper/mdx/Reference.astro"; +import ReferenceMarker from "@/components/features/whitepaper/mdx/ReferenceMarker.astro"; + +

    + +_本ホワイトペーパーは情報提供のみを目的としており、いかなる有価証券、投資、または金融商品の売却の申し出、買付けの申し出の勧誘、または推奨を構成するものではありません。読者は投資判断を行う前に独自のデューデリジェンスを行い、資格を有する専門家に相談してください。Quantus Networkは、ここに含まれる情報の正確性または完全性について表明または保証を行いません。_ + +

    + 目次 +

    + + + +
    + + + +### 量子の脅威 + +従来のブロックチェーンは、暗号学的に意味のある量子コンピュータ(CRQC)による存亡の脅威に直面しています。ブロックチェーンの暗号基盤は離散対数問題(DLP)の困難さに依存しており、量子アルゴリズム、特にショアのアルゴリズムは、古典コンピュータよりもDLPを指数的に速く解くことができます。この脆弱性により、量子的な攻撃者が公開鍵から秘密鍵を導き出し、取引の偽造や機密性の高い金融データの復号が可能になる恐れがあります。 + +> 耐量子計算への先回り的なアップデートがなければ、数兆ドル規模の暗号経済は、こうした攻撃による突然の価値毀損のリスクにさらされます。 + +### 独自の価値提案 + +ラテン語で「どれほど」を意味する語にちなんで名付けられたQuantus Networkは、スケーラブルで量子的に安全なプライベートマネーを実現します。Quantusは汎用スマートコントラクト・プラットフォームではありません。少数の料理に徹して磨きをかけるレストランのように、Quantusは次を提供します。 + +- すべてのトランザクションに対する耐量子署名 +- ピア間接続を保護する耐量子署名と暗号化(ML-DSAおよびML-KEM) +- スケーリングのための耐量子ゼロ知識証明 +- 盗難を抑止し、ミスからの回復を可能にする高セキュリティアカウント +- アドレス確認を容易にする人間が読めるチェックフレーズ + +スケーラブルで量子的に安全なプライベートマネーに焦点を当てる判断は、CRQCが業界にもたらす脅威と、ビットコインがこれらの課題に対処できないことに由来します。 + + + +### 量子計算の基礎 + +量子コンピュータは、重ね合わせやもつれなどの原理を利用して、古典マシンでは扱いにくい計算を行います。0または1である古典ビットとは異なり、量子ビット(qubit)は複数の状態に同時に存在でき、特定の問題に対して指数的な並列性を可能にします。この能力は、ブロックチェーン金融を支える暗号システムに存亡のリスクをもたらします。量子ハード向けに開発されたアルゴリズムが、公開鍵暗号の大半のセキュリティ前提を覆すためです。 + +**ショアのアルゴリズム**は、1994年にピーター・ショアによって発表され、量子コンピュータ上で大きな整数の因数分解と離散対数問題を多項式時間で解く手法を示しました。量子フーリエ変換(QFT)を用いて関数の周期を求め、RSAや楕円曲線暗号(ECC)などの方式の基盤となる落とし戸関数を効率的に反転できます。ブロックチェーン金融では、十分に強力な量子コンピュータ(推定約2,000論理量子ビット)を持つ攻撃者が、多項式時間 O(n³) で公開鍵から秘密鍵を導き出せることを意味します。極めて大きな加速であり、脆弱なシステムを一晩で時代遅れにします。 + +**グローバーのアルゴリズム**は、1996年にラヴ・グローバーによって提案され、非構造化探索に対して二次の加速を与え、探索時間を O(n) から O(√n) 操作に短縮します。非対称暗号に対するショアほど壊滅的ではありませんが、グローバーはハッシュ関数やAES暗号などの対称プリミティブに影響し、実質的にセキュリティレベルを半分にします(例:256ビット鍵が量子攻撃下では128ビット相当に振る舞う)。この攻撃は、暗号方式を変えるのではなくセキュリティビットを倍にすることで緩和されます。また、グローバーの二次加速は量子ビットとゲート要件が高く、並列化が限られた数十億の逐次操作を要するため、将来のハードでも現実世界での逆転には不向きです。 + +### 4つの脅威カテゴリ + +#### 01 - デジタル署名の偽造 + +ショアのアルゴリズムは、多くのブロックチェーンで使われるECCベースの署名(例:ビットコインのsecp256k1曲線)を直接脅かし、攻撃者がユーザーになりすまして不正なトランザクションを承認できるようにします。この能力は、ブロックチェーンの最も基本的な機能の致命的な失敗を意味します。 + +#### 02 - ゼロ知識システムにおける偽証明の偽造 + +プライバシー重視の金融におけるzk-SNARKなど、多くのゼロ知識証明は、コミットメントに楕円曲線ペアリングを介した離散対数の困難さに依存しています。ショアにより、有効に見える無効な証明が作れ、攻撃者が新規コインを鋳造したりL2の状態を偽装したりできる可能性があります。 + +#### 03 - 秘密情報の復号 + +量子攻撃は、ZcashやMoneroなどのプライバシー・プロトコルで脆弱な公開鍵方式で保護された暗号化データを露呈させる可能性があります。金融プロトコルにおけるP2P通信を復号し、機密性の高い資産の詳細を明らかにし、標的を絞った盗難を可能にする恐れもあります。 + +#### 04 - ハッシュ関数の反転 + +グローバーのアルゴリズムは、プルーフ・オブ・ワークやアドレス生成に使われるSHA-256などのハッシュに対する原像攻撃を加速しうるが、最も心配の少ない脅威です。多くの耐量子方式は、十分な大きさのダイジェストであればハッシュは十分安全とみなされるハッシュベースの構成を取り入れています。 + +### 耐量子暗号におけるスケーリングの課題 + +耐量子暗号(PQC)は量子脅威に対する不可欠な保護を提供しますが、これらのアルゴリズム固有の設計により、重大なスケーリング上の障壁を生みます。コンパクトな数学構造に依拠する楕円曲線方式とは異なり、PQCプリミティブは古典および量子の両方の攻撃者に対してセキュリティを維持するために、より大きなパラメータを必要とします。その結果、公開鍵、秘密鍵、署名がしばしば桁違いに大きくなります。次の表は、128ビットの耐量子セキュリティレベルにおけるML-DSAの代表的なサイズを、256ビットECDSAなどの古典的対応物と比較したものです。 + + + +128ビット耐量子セキュリティレベルにおけるサイズ。出典:Open Quantum Safe Project + +ご覧のとおり、ML-DSAの署名はECDSA相当より70倍以上、公開鍵は80倍以上大きくなり得ます。他のPQCファミリーはさらに悪化します。SPHINCS+のようなハッシュベース方式は最大41 KBの署名を生み、FALCONのようなサイズ最適化格子バリアントでも古典サイズを大きく上回ります。 + +ブロックチェーンの文脈では、これらの肥大化したサイズがシステム全体のスケーリング問題に積み上がります。大きな署名は個々のトランザクションを膨らませ、ブロックが早く埋まり検証に時間がかかることで秒間トランザクション数(TPS)を下げます。P2P通信にも負荷がかかり、帯域と伝播遅延が増し、プルーフ・オブ・ワークなどのコンセンサスでフォークや孤立ブロックのリスクを高めうります。ストレージ要件も影響を受け、ノードの運用コストが上がり、特にリソースの限られたユーザーやバリデータの参加障壁となります。 + + + こうしたスケーリング課題は、将来すべてのブロックチェーンが対処しなければなりません。例えばビットコインは、最大ブロックサイズを増やさなければ1 + TPSを大きく下回ります。 + + + + +### 調整問題 + +ビットコインの保守的文化はプロトコル変更に抵抗します。PQCの改善には、移行期限、コインの没収の可能性、ブロックサイズの増加など、論争的な事項についてのコンセンサスが必要です。たとえコミュニティが合意しても、各ユーザーは資金を量子的に安全な新しいアドレスへ移行しなければなりません。移行はすべての暗号資産保有者の行動を要し、その多くはウォレットへのアクセスを失っているか、脅威を認識していません。 + +これらの問題は公開ブロックチェーン全体にありますが、明確なリーダーシップの欠如と技術的硬直化の哲学により、ビットコインでは特に困難です。 + +### 紛失コインの問題 + +推定2,500億~5,000億ドル相当のビットコインが、紛失した鍵、死亡した保有者、忘れられたウォレットにより恒久的にアクセス不能です。[3] これらのコインは移行できず、暗号学的に意味のある量子コンピュータ(CRQC)を作るための公的報酬として機能します。量子攻撃者は移行されていない公開鍵から秘密鍵を導き出し、数十億ドル相当のBTCを市場に流し込む可能性が高いでしょう。 + +> 技術的に唯一の解は、移行されないコインを凍結する厳格な期限を設けることだが、 +> 政治的には不可能である。 + +そのような期限がなければ、移行されないコインは盗まれ売却され、市場を押し下げ、ネットワークへの信頼を損ないます。 + +### 移行スケジュールの問題 + +耐量子署名は現行のビットコイン署名の20~80倍の大きさです。根本的なアーキテクチャ変更なしに、ビットコインの性能はすでに限られた容量のわずかな割合に崩落します。 + +ビットコインが政治的・技術的課題を解決したとしても、移行自体は数ヶ月から年単位かかります。各保有者は、資金を量子的に安全なアドレスへ動かすために少なくとも1件のトランザクションを送る必要があります。多くはまずテスト送金を行います。肥大したPQC署名が性能を窒息させる中、脆弱なコインがさらさら露呈したまま、ネットワークは数ヶ月から年単位のキューに直面します。 + + + こうした積み重なった課題により、既存チェーンへの量子セキュリティ追加は極めて困難です。 + Quantus + Networkは、初日からチェーンに量子セキュリティを組み込むことでこれを回避します。 + + + + +### 基礎 + +Quantus Networkは、EthereumとPolkadotの背後にあるParity Technologiesチームが開発したブロックチェーンSDK、Substrateの上に構築されています。Substrateは高度にモジュール式であり、Quantusを独自にする部分に集中するためにコンポーネントを容易に差し替えられます。 + +QuantusはSubstrateを次のように強化します。 + +- 耐量子署名方式のサポート追加 +- P2Pネットワークのセキュリティを耐量子に更新 +- ユーザー制御のトランザクション可逆性の追加 +- すべてのデータ型をフィールド要素の境界に揃え、データベースをZK互換にする + +### 耐量子暗号プリミティブ + +Quantus Networkは、NISTが標準化したPQCを用いて、トランザクションとネットワーク通信のセキュリティを量子脅威から保護します。トランザクション整合性の中核には**ML-DSA**(モジュール格子ベースのデジタル署名アルゴリズム、旧称CRYSTALS-Dilithium)があり、セキュリティ、効率、実装のしやすさのバランスから格子ベースの署名方式として選ばれています。ML-DSAは、モジュール格子上のLearning With Errors(LWE)やShort Integer Solution(SIS)などの問題の困難さを利用し、ショアのアルゴリズムを含む古典・量子攻撃に対して頑健な耐性を提供します。 + +トランザクション署名には、Quantusが**ML-DSA-87**を統合しています。これはNISTの最高セキュリティレベル(レベル5、古典256ビット・量子128ビット相当)のパラメータ集合であり、格子暗号解析の進展に備えた慎重さを優先します。格子暗号は比較的新しく、古典方式ほど実戦で試されていません。より大きなパラメータは格子解析の潜在的進展によるリスクを緩和し、小さな鍵サイズはより弱い標的のまま残ります。 + +#### 検討した代替案 + +ML-DSAは、FN-DSA(Falcon)などの代替より選ばれました。Falconは実装が複雑(例:ブロックチェーンに不向きな浮動小数点演算が必要)、仕様に決定論的鍵生成がなく、開発当時は最終化されていませんでした。 + +SLH-DSAのようなハッシュベース方式は、さらに大きな署名(17 KB超)のため選ばれませんでした。暗号アジリティ(署名方式の切り替え能力)はSubstrateに組み込まれており、将来状況が変わればこれらの代替を比較的容易に追加できます。 + +ML-DSA-87は鍵と署名が大きいものの、初期段階のQuantusネットワークではストレージがまだボトルネックではなく管理可能であり、ワームホールアドレスによるゼロ知識証明などの最適化がスケーリングに対処します。 + +実装の技術詳細は [QIP-0006](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0006.md) を参照してください。 + +### LibP2P - 量子的に安全なネットワーク + +Quantus Networkは、ピアツーピア(P2P)ノード間通信を、認証に**ML-DSA**、鍵のカプセル化に**ML-KEM**(モジュール格子ベース鍵カプセル化メカニズム、旧CRYSTALS-Kyber)を組み合わせて保護します。この統合はPQCをlibp2pスタックまで拡張し、量子耐性のため中核コンポーネントを変更します。ML-DSA-87によるピア識別と、共有秘密の量子耐性のためNoiseハンドシェイクをKEMメッセージで拡張したML-KEM-768によるトランスポートセキュリティです。 + +P2P層は量子セキュリティ分析で見落とされがちです。ピア認証は重要ですが、ピア層で攻撃者が最悪行えるのはノードになりすまして無効なメッセージを送ることであり、これはサービス拒否にすぎません。この攻撃は、ブロックチェーンではノードは通常信頼されず、攻撃が検知されれば鍵を容易に変更できるため、すでに緩和されています。同様に、P2P通信の復号は攻撃者への利益が限定的(例:トランザクション経路の追跡はプロキシやTorで緩和)で、多くのデータは最終的にチェーン上で公開されます。 + +それでも、P2P層を量子的に保護することは、盗聴、中間者攻撃、量子による復号から守り、ノードのゴシップ、ブロック伝播、その他のネットワーク相互作用が予見可能な将来にわたって機密性と整合性を保つことを意味します。 + +技術詳細は [QIP-0004](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0004.md) を参照してください。 + +### PQCスケーリング - ワームホールアドレス + +耐量子暗号に内在するスケーリング課題に対処するため、Quantus Networkは**「ワームホールアドレス」**と呼ばれる、革新的な集約耐量子署名方式を導入します。このシステムは、Plonky2証明システム(基本的にSTARK)で生成されたゼロ知識証明(ZKP)を利用し、残高検証をオフチェーンに移し、チェーンは個々の署名を処理せず単一のコンパクトな証明だけを検証できます。ワームホールアドレスは、1本の証明で多数のトランザクションを検証でき、公開入力(例:ヌリファイア、ストレージルート、出力アドレス、金額)が主な制約要因です。これにより、トランザクションあたり償却されるストレージ需要は約256バイトの追加に抑えられ、既知のいかなるPQC署名方式よりもはるかに小さくなります。 + +方式の量子セキュリティは、従来のSNARKで量子に弱い楕円曲線ペアリングの代わりに、FRI(Fast Reed-Solomon Interactive Oracle Proofs)によるコミットメントに**Poseidon2**という安全なハッシュ関数を用いることに由来します。 + +さらに、認証秘密はPoseidon2の背後に隠されます。安全なハッシュ関数はグローバーのアルゴリズムでせいぜい二次的に弱まるだけであり、破られません。ハッシュ原像証明はZK文脈でSPHINCS+のようなハッシュベース方式に似た、軽量の耐量子署名として機能し得ます。 + +#### クライアント/証明者フロー + +ユーザーは、ソルトと秘密を連結したものを二重ハッシュし、支出不能であることが証明可能なアドレスを生成します。 + +``` +H(H(salt|secret)) +``` + +この構成は、単純ハッシュ公開鍵と二重使用不能アドレスを混同するような偽陽性を防ぎます。Substrate(および一般的にブロックチェーン)では、アドレスは安全なハッシュではなく、秘密鍵から代数演算で導かれた公開鍵の単純ハッシュです。構成のセキュリティは、安全なハッシュの原像の原像を見つけることに帰着します。このアドレスへ送られたトークンは事実上バーンされます。受取アドレスに対応する秘密鍵が存在しないため使用できません。これらのコインは供給を膨らませずに再鋳造できます。 + +各送金ごとに、グローバルな一意の送金回数などの詳細を含むTransferProofストレージオブジェクトが作成されます。ユーザーのウォレットは、最近のブロックヘッダのストレージルートからこのTransferProofのリーフまでのMerkle-Patricia-Trie(MPT)ストレージ証明を生成します。二重使用を防ぐためヌリファイアを計算します。 + +``` +H(H(salt | secret | global_transfer_count)) +``` + +#### アグリゲーターフロー + +任意の当事者(クライアント、マイナー、第三者)がPlonky2の再帰により複数の証明を集約し、各親証明が子を検証する証明の木を形成し、子の公開入力を集約します。 + +- ヌリファイアはそのまま渡る +- 出力アドレスは重複除去される +- ブロックハッシュは連鎖が証明され、最新以外は破棄される +- 重複出力アドレスの金額は合算される + +#### チェーン/検証者フロー + +ネットワークは集約証明を検証し、ブロックハッシュがチェーン上で最近であること、ヌリファイアの一意性(二重使用防止)、証明の有効性を確認します。ZK回路はストレージ証明の正しさ、ヌリファイアの正確さ、アドレスの使用不能性、入出力の残高一致、ブロックヘッダの連鎖を課します。 + +#### Plonky2を選ぶ理由 + +- すでに監査済み +- 耐量子 +- 信頼初期設定不要 +- 証明/検証が効率的 +- 証明の集約がスムーズ +- Rustでのネイティブ実装 +- Substrateのno-std環境と相性が良い + + + 再帰証明は約170ミリ秒で終了し、サイズはコンパクトです(集約証明あたり100 + KB)。5 + MBブロックで最適な場合、すべてのトランザクションが同一出力先なら、ワームホールアドレスは1ブロックあたり約153,000件を詰め込めます(4.9 + MB/ヌリファイア32バイト):生のML-DSA約685件(5 MB/7.3 + KB)に対して約223倍の改善です。 + + +#### セキュリティ上の注意 + +潜在的リスクには、回路/検証実装の不具合によるインフレーション・バグが含まれますが、再鋳造コインがゼロ送金元アドレスの残高を超えるなら経済的に検出可能です。ユーザーは秘密を開示せず最初のハッシュを公開することで、任意にワームホールアドレスであることを証明できます。検証トランザクションは署名されないため、失敗トランザクションによるDoSは金融的手段なしで緩和する必要があります。トークン供給の計算は維持され、再鋳造は新規コインとして現れますが、バーンにより最大供給保証が保たれます。 + +さらなる技術詳細は [QIP-0005](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0005.md) を参照してください。 + +### コンセンサスメカニズム + +Quantus Networkは、ビットコインのコンセンサスの望ましい性質を保ちつつ、ZK証明システムとの親和性を高めるためSHA-256を**Poseidon2**に置き換えることで、プルーフ・オブ・ワーク(PoW)コンセンサスアルゴリズムを用います。 + +重要:この変更は量子セキュリティのためではありません。SHA-256のような暗号ハッシュ関数は、特にグローバーのアルゴリズムにより弱まりますが破壊されません。一部の耐量子署名方式はこの理由で安全なハッシュを基本ブロックとして使います。 + +Poseidon2はPoseidonハッシュ関数の改良版です。SHA-256のような従来ハッシュでの計算用にSNARKやSTARKを作ると、Poseidonを使う場合の約100倍のゲートが必要になることが多く、Poseidonはビット演算ではなくフィールド要素上の代数関数のみに依拠します。 + +Poseidon2とPlonky2には**ゴールドィロックス体**を用います。ゴールドィロックス体の位数は64ビット符号なし整数に収まり、堅牢性を損なわず効率を高めます。 + + + +暗号資産の鍵管理には多くのリスクがありますが、ほとんどは避けられます。 + +### 可逆トランザクション + +Quantus Networkは、ユーザーが設定できる可逆トランザクションを提供します。送信者は、送金をキャンセルできる時間窓を設定します。これにより盗難を抑止し、ファイナリティを犠牲にせずミスを修正できます。システムはタイムスタンプ付きの修正されたSubstrate「scheduler」パレットを用います。ウォレットは送信者(キャンセルボタン付き)と受取人にカウントダウンを表示します。 + +可逆トランザクションは、オンチェーン適用によって分散性を保ちながら、新しいセキュリティ・プロトコルを可能にします。 + +技術詳細は [QIP-0009](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0009.md) を参照してください。 + +### チェックフレーズ + +Quantus Networkは「check-phrases」を導入します。これはブロックチェーンアドレスに対する、人間が読め暗号的に安全なチェックサムです。アドレスをハッシュしてBIP-39の単語リストから短い覚えやすい語列を生成します。チェックフレーズは誤字、改ざん、住所汚染攻撃から保護します。50,000回反復の鍵導出関数によりレインボーテーブル攻撃を高コストにします。大金の送金では、ユーザーは引き続きアドレスを文字単位で確認すべきです。 + +技術詳細は [QIP-0008](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0008.md) を参照してください。 + +### 高セキュリティアカウント + +任意のアカウントを、すべての送金に必須の可逆期間を伴う「高セキュリティアカウント」に格上げできます。指定した**ガーディアン**(ハードウェアウォレット、マルチシグ、または信頼できる第三者)が可逆期間中に疑わしいトランザクションをキャンセルし、資金を送信者または受取人ではなくガーディアンへ送れます。このオプトイン機能は一度有効化すると恒久的で、盗賊が無効化できません。 + +ガーディアンは連鎖できます。高セキュリティアカウントのガーディアン自体を、独自のガーディアンを持つ高セキュリティアカウントにできます。これにより、保護するアカウントに対して上位の権限を持つ合成可能な階層が生まれます。正当な送金のファイナリティを損なわず、ユーザーが不正活動に気づき対応する時間を確保する設計です。 + +技術詳細は [QIP-0011](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0011.md) を参照してください。 + +### 鍵の回収 + +多くの暗号資産の富は、所有者とともに墓場へ運ばれました。Quantus Networkは、固定遅延のもとでいつでも資金を引き出せる回復用アドレスを簡単に指定する方法を提供します。その間、所有者が鍵にアクセスできれば回復を拒否できます。この機能は存続を可能にします。裁判所や正式な遺言なしにオンチェーンの遺言を持てます。 + +### HD-Lattice + +階層的决定論的(HD)ウォレットは業界標準であり、すべての鍵を1つのシードフレーズでバックアップでき、手動コピーよりセキュリティと利便性が向上します。Dilithiumのような格子方式に適合させると2つの課題があります。 + +- HMAC-SHA512の出力は、特定の性質を持つ環からサンプリングされた多項式である格子秘密鍵を直接形成できない。 +- 非ハード化鍵導出は楕円曲線上の加算に依拠するが、格子には存在しない(公開鍵はどの代数演算でも閉じない)。 + +Quantus Networkは前者を、HMAC出力を鍵そのものではなく、秘密鍵を決定論的に構築するエントロピーとして用いることで対処します。後者は格子暗号がそれを解決するよう適合できれば未解決の研究課題にすぎず、緊急度は低いです。 + +技術詳細は [QIP-0002](https://github.com/Quantus-Network/improvement-proposals/tree/main/qip-0002) を参照してください。 + + + +Quantus Networkは変化する環境にあり、初手で正解だと仮定することはできません。そこで単純な出発点を選び、新たな情報に応じてガバナンスが変更できるようにしました。この設計により、ブロックチェーンは環境に適応できる生きた実体になります。特にSubstrateのガバナンスプロセスは、各種ノード運用者間の調整を最小限に、チェーンへの深い変更を可能にします。 + +### ブロック報酬 + +Quantus Networkは、ビットコインを模した単純なトークノミクスモデルを採用します。最大供給は**2,100万枚**で、単純なヒューリスティックがブロック報酬を決めます。 + +``` +block_reward = (max_supply - current_supply) / constant +``` + +このヒューリスティックは、block_rewardがcurrent_supplyに寄与するにつれ滑らかに指数関数的に減少する曲線を形成し、次ブロックで計算されるblock_rewardを下げます。手数料などによるバーンはcurrent_supplyを減らし、ブロック報酬の予算の一部になります。定数は、バーンが全くない場合に約30年でコインの99%が発行されるよう選ばれています。 + +### 投資家への割当 + +Quantus Networkは、資金提供で大きなリスクを負った投資家の支援により構築されました。プライベート投資家はチームと同様に4年のベスティングに服します。公募投資家は初日から完全に流動性があります。公募で調達した資金はトークンとペアリングされ、流動性(DEX、CEX、マーケットメイカー)に使われます。これらの投資家割当と流動性が唯一の「プレマイン」です。残りのトークンは存在するまでマイニングで発行されます。 + +公募で最大10%未満しか売れなかった場合、流動性トークンは比例して削減され、残りはブロック報酬としてマイナーに発行されます。 + +### 会社への割当 + +新技術を成功の保証なく構築するリスクを負ったチームへの補償として、約4年間、ブロック報酬の一部が会社に送られます。これは会社への**総供給の約15%**に相当する事実上のベスティングです。 + +その時点以降、ブロック報酬における会社のシェアは、トークン保有者の投票によりオフ、調整、または再配向できます。 + +### トランザクション手数料 + + + +### フォークレスアップグレード + +Quantus Networkは、Substrateのランタイムアップグレードにより「フォークレス」アップグレードをサポートし、ブロックチェーンの中核ロジック(「ランタイム」)を、ネットワークを混乱させたりコミュニティを分断するハードフォークなしに進化させられます。オンチェーンガバナンスの公投で実現し、承認された提案がランタイムの入れ替えを発動します。既存のWASMコードblobを新しいものに実質1ブロックで置き換え、状態と運用の連続性を保ちます。この経路はダウンタイムとリスクを最小化し、実利用から改善が見えてくるにつれコミュニティが反復的にプロトコルを洗練できるようにします。 + +コミュニティがシステムへの信頼を深めるにつれ、悪意ある主体がアップグレード過程を掌握した場合の攻撃面を抑えるため、ランタイム変更の権限は大幅に縮小されます。 + +### ガバナンス体制 + +Quantus Networkのガバナンス枠組みは、Substrate経由でPolkadotのOpenGovを継承します。トークン保有者は**信念投票**に参加し、資産を可変期間ロックして票の重みを増幅します。増幅は1倍(ロックなし)から最大6倍(最大ロック)までです。この設計は、コミットメントに影響力を結びつけることで長期の利害一致を促します。 + +提案は**オリジン**と呼ばれる複数の投票トラックに分類されます。各オリジンは、高影響変更の超過半数などの承認閾値、スパム対策の最低預金、準備/実行期間、膠着回避の決定期限など、カスタムパラメータを持ちます。このマルチトラック設計により、日常のトレジャリー支出から重要なランタイム更新まで、多様な公投を並行処理できます。 + +**Technical Collective**は、技術専門家のキュレートされたグループで、緊急の技術案件を提案・レビュー・ホワイトリストし、コミュニティ監督を維持しつつ専用トラックで迅速化する専門機関として機能します。 + +Quantusはこのシステムを改変せず採用しますが、初期段階の複雑さを避けるためミニマルな設定から始めます。当初はTechnical Collectiveのトラックのみが有効で、プロトコル更新やパラメータ調整などの高権限の拘束力ある決定に用いられます。 + +のちにQuantusは、機能提案やエコシステム調査など執行力のない事項についてコミュニティ向けの非拘束投票トラックを追加できます。会社がネットワークをDAOに引き渡したとき、この仕組みは拘束力を持ちます。この段階的アプローチにより、ネットワークは将来のガバナンス投票で有機的に進化でき、初期からユーザーに不要な複雑さを負わせません。 + + + +2026年までの現行ロードマップ(変更の可能性あり)。 + + + + + + + + + + + + + + + +
    + + + +Quantus Networkの構築には固有のリスクが伴います。 + +### 実装上の問題 + +設計の優れたシステムでも、ソフトウェアロジックの欠陥は重大な障害を引き起こし得ます。 + +### NISTアルゴリズム選定上の問題 + +標準化後に、選ばれた耐量子標準(例:ML-DSA、ML-KEM)に欠陥やバックドアが現れる可能性。最悪の場合、そのような欠陥は公開鍵から秘密鍵を導き署名を偽造できる攻撃者を可能にし、チェーンに壊滅的な故障モードをもたらします。欠陥が公表されればQuantus Networkは新アルゴリズムへ更新できますが、希少な悪用では発見されないかもしれません。 + +### 量子計算のタイムライン + +量子の進展は予想よりずっと遅れ、PQCの必要性を先延ばしにする可能性があります。逆に、政府による秘密開発などが、ブロックチェーンコミュニティが迅速に更新しなければ突然の脅威となる可能性があります。 + +### その他の考慮 + +一般的な採用障壁、金融/ブロックチェーンにおける規制の不確実性、暗号エコシステムに内在するボラティリティ。 + + + +
    + + + Shor, P. W. (1997). Polynomial-time algorithms for prime factorization and + discrete logarithms on a quantum computer. _SIAM Journal on Computing_, 26(5), + 1484–1509. https://doi.org/10.1137/S0097539795293172 + + + + Grover, L.K. (1996). A fast quantum mechanical algorithm for database search. + _Proceedings of the Twenty-Eight Annual ACM Symposium on Theory of Computing_, + 212-219. https://doi.org/10.1145/237814.237866 + + + + Chainalysis. (2024). _The Chainalysis 2024 Crypto Crime Report_. + https://www.chainalysis.com/blog/2024-crypto-crime-report-introduction/ + + + + National Institute of Standards and Technology. (2024). _FIPS 204: + Module-Lattice-Based Digital Signature Standard (ML- DSA)_. U.S. Department of + Commerce. https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf + + + + National Institute of Standards and Technology. (2024). _FIPS 203: + Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)_. U.S. + Department of Commerce. + https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf + + + + Häner, T., Jaques, S., Naehrig, M., Roetteler, M., & Soeken, M. (2020). + Improved quantum circuits for elliptic curve discrete logarithms. + _arXiv:2002.12480_. https://arxiv.org/abs/2002.12480 + + + + Gidney, C., & Ekerå, M. (2021). _How to factor 2048 bit RSA integers in 8 + hours using 20 million noisy qubits_. _arXiv:1905.09749_. + https://arxiv.org/abs/1905.09749 + + + + Aggarwal, D., et al. (2021). Assessment of Quantum Threat To Bitcoin and + Derived Cryptocurrencies. _ePrint IACR_. https://eprint.iacr.org/2021/967.pdf + + + + Roetteler, M., Naehrig, M., Svore, K. M., & Lauter, K. (2017). Quantum + resource estimates for computing elliptic curve discrete logarithms. + _arXiv:1706.06752_. https://arxiv.org/abs/1706.06752 + + + + Open Quantum Safe Project. (n.d.). ML-DSA | Open Quantum Safe. Retrieved + January 29, 2026, from + https://openquantumsafe.org/liboqs/algorithms/sig/ml-dsa.html + diff --git a/website/src/contents/whitepapers/ko-KR/v0.3.3.mdx b/website/src/contents/whitepapers/ko-KR/v0.3.3.mdx new file mode 100644 index 0000000..fde6a75 --- /dev/null +++ b/website/src/contents/whitepapers/ko-KR/v0.3.3.mdx @@ -0,0 +1,524 @@ +--- +title: "Quantus Network Whitepaper" +version: "0.3.3" +publishedDate: "2026-03-21" +updatedDate: "2026-03-21" +authors: ["Christopher Smith"] +changelog: + - "대폭 개정: 법적 고지, 목차, 번호가 붙은 장(01–09), PDF 표지, TOC; 맺음말 대신 「참고문헌 및 추가 읽을거리」." + - "신규 장: 이전 위기(조정 문제, 분실 코인, PQC 이전 일정)." + - "서론 및 양자 위협 절 재작성: CRQC 프레이밍, 네 가지 번호 위협 범주, 본문 인용." + - "아키텍처 및 기술 절 확장·명확화(Foundation/Substrate, LibP2P, wormhole/Plonky2, 합의/Goldilocks 필드)." + - "로드맵: Bell 메인넷 2026년 2분기; Fermi 업그레이드 2026년 4분기; Planck 베타에 ZK 통합 추가." +pdfCover: true +# Astro `render().headings`는 JSX `

    `와 ChapterHeading을 포함하지 않습니다. 앵커 slug는 Markdown `###` id와 같습니다. +toc: + insertBefore: + 양자-위협: + - slug: legal-disclaimer + text: 면책 조항 + - slug: contents + text: 목차 + - slug: chapter-01 + text: 서론 + 양자-컴퓨팅-기초: + - slug: chapter-02 + text: 블록체인에 대한 양자 위협 + 조정-문제: + - slug: chapter-03 + text: 마이그레이션 위기 + 기초: + - slug: chapter-04 + text: Quantus Network 아키텍처 + 가역-트랜잭션: + - slug: chapter-05 + text: 자산 보존 + 블록-보상: + - slug: chapter-06 + text: 토크노믹스와 거버넌스 + 구현-문제: + - slug: chapter-07 + text: 로드맵 + - slug: chapter-08 + text: 리스크 + insertAfter: + 기타-고려: + - slug: chapter-09 + text: 참고문헌 및 추가 읽을거리 +--- + +import CalloutV2 from "@/components/features/whitepaper/mdx/CalloutV2.astro"; +import Figure from "@/components/features/whitepaper/mdx/Figure.astro"; +import Grid from "@/components/features/whitepaper/mdx/Grid.astro"; +import Column from "@/components/features/whitepaper/mdx/Column.astro"; +import TimelineV2 from "@/components/features/whitepaper/mdx/TimelineV2.astro"; +import ResponsiveTableV2 from "@/components/features/whitepaper/mdx/ResponsiveTableV2.astro"; +import SiteSocials from "@/components/ui/SiteSocials.astro"; +import OrderedList from "@/components/features/whitepaper/mdx/OrderedList.astro"; +import Divider from "@/components/features/whitepaper/mdx/Divider.astro"; +import ChapterHeading from "@/components/features/whitepaper/mdx/ChapterHeading.astro"; +import Reference from "@/components/features/whitepaper/mdx/Reference.astro"; +import ReferenceMarker from "@/components/features/whitepaper/mdx/ReferenceMarker.astro"; + +

    + +_본 백서는 정보 제공 목적으로만 제공되며, 어떠한 증권·투자 또는 금융 상품에 대한 매도 제안, 매수 제안의 권유 또는 권고를 구성하지 않습니다. 독자는 투자 결정을 내리기 전에 스스로 충분한 실사를 수행하고 자격을 갖춘 전문가와 상담해야 합니다. Quantus Network는 여기에 포함된 정보의 정확성이나 완전성에 대해 어떠한 진술이나 보증도 하지 않습니다._ + +

    + 목차 +

    + + + +
    + + + +### 양자 위협 + +전통적인 블록체인은 암호학적으로 의미 있는 양자 컴퓨터(CRQC)로 인한 실존적 위협에 직면합니다. 블록체인의 암호학적 기반은 이산 로그 문제(DLP)의 난이도에 의존하며, 쇼어(Shor) 알고리즘을 포함한 양자 알고리즘은 DLP를 고전 컴퓨터보다 기하급수적으로 빠르게 풀 수 있습니다. 이러한 취약점은 양자 공격자가 공개 키에서 개인 키를 도출해 거래를 위조하고 민감한 금융 데이터를 복호화할 수 있게 할 수 있습니다. + +> 선제적이고 양자 내성 컴퓨팅에 맞춘 업데이트가 없다면, 수조 달러 규모의 크립토 경제는 그러한 공격으로 인한 급격한 가치 하락 위험에 처합니다. + +### 독특한 가치 제안 + +라틴어로 「얼마나」를 뜻하는 말에서 이름을 딴 Quantus Network는 확장 가능하고 양자 의미에서 안전한 사적 화폐(private money)를 가능하게 합니다. Quantus는 범용 스마트 컨트랙트 플랫폼이 아닙니다. 소수의 요리에 집중하는 레스토랑처럼, Quantus는 다음을 제공합니다. + +- 모든 트랜잭션에 대한 포스트 퀀텀 서명 +- 피어 간 연결을 보호하기 위한 포스트 퀀텀 서명 및 암호화(ML-DSA 및 ML-KEM) +- 확장을 위한 포스트 퀀텀 영지식 증명 +- 도난을 억제하고 실수로부터 복구를 가능하게 하는 고보안 계정 +- 주소를 간단히 검증할 수 있는 읽기 쉬운 확인 문구(check-phrases) + +확장 가능하고 양자 의미에서 안전한 사적 화폐에 집중하기로 한 결정은 CRQC가 업계에 제기하는 위협과 비트코인이 이러한 과제를 다루지 못한다는 점에서 비롯됩니다. + + + +### 양자 컴퓨팅 기초 + +양자 컴퓨터는 중첩과 얽힘 같은 원리를 활용해 고전 기계로는 다루기 어려운 계산을 수행합니다. 0 또는 1인 고전 비트와 달리 큐비트는 동시에 여러 상태에 존재할 수 있어, 특정 문제에 대해 기하급수적 병렬성을 허용합니다. 이러한 능력은 블록체인 금융을 뒷받침하는 암호 시스템에 실존적 위험을 제기합니다. 양자 하드웨어용으로 개발된 알고리즘이 대부분의 공개 키 암호화 보안 가정을 무너뜨리기 때문입니다. + +**쇼어 알고리즘**은 1994년 피터 쇼어(Peter Shor)가 제시한 것으로, 양자 컴퓨터에서 큰 정수의 인수분해와 이산 로그 문제를 다항 시간에 푸는 방법을 제공합니다. 양자 푸리에 변환(QFT)을 이용해 함수의 주기를 찾아 RSA나 타원곡선 암호(ECC) 등을 뒷받침하는 트랩도어 함수를 효율적으로 역전시킬 수 있습니다. 블록체인 금융 관점에서, 충분히 강력한 양자 컴퓨터(논리 큐비트 약 2,000개로 추정)를 가진 공격자는 공개 키에서 개인 키를 다항 시간 O(n³)에 도출할 수 있습니다. 이는 극단적인 가속으로, 취약한 시스템을 하룻밤 사이에 구식으로 만듭니다. + +**그로버 알고리즘**은 1996년 러브 그로버(Lov Grover)가 제안한 것으로, 비구조화된 검색에 대해 이차 가속을 제공해 검색 시간을 O(n)에서 O(√n) 연산으로 줄입니다. 비대칭 암호에 대한 쇼어만큼 파괴적이지는 않지만, 그로버는 해시 함수와 AES 암호화 같은 대칭 프리미티브에 영향을 미쳐 실질적으로 보안 수준을 절반으로 줄입니다(예: 256비트 키가 양자 공격에 대해 128비트처럼 동작). 이 공격은 암호 체계를 바꾸는 대신 보안 비트를 두 배로 늘리는 방식으로 완화됩니다. 또한 그로버의 이차 가속은 높은 큐비트·게이트 요구와 제한된 병렬화로 인해 수십억 번의 순차 연산이 필요해, 미래 하드웨어에서도 실제 역전에는 비현실적입니다. + +### 네 가지 위협 범주 + +#### 01 - 디지털 서명 위조 + +쇼어 알고리즘은 대부분의 블록체인에서 사용하는 ECC 기반 서명(예: 비트코인의 secp256k1 곡선)을 직접 위협하여, 공격자가 사용자를 사칭하고 사기성 트랜잭션을 승인할 수 있게 합니다. 이러한 능력은 블록체인의 가장 기본적인 기능에 대한 치명적 실패를 의미합니다. + +#### 02 - 영지식 시스템에서 가짜 증명 위조 + +프라이버시 중심 금융을 위한 zk-SNARK 등 많은 영지식 증명은 커밋에 타원곡선 페어링을 통한 이산 로그 난이도에 의존합니다. 쇼어는 유효해 보이는 무효한 증명을 만들 수 있게 하여, 공격자가 새 코인을 발행하거나 레이어 2(L2) 상태를 위조할 수 있게 할 수 있습니다. + +#### 03 - 비밀 정보 복호화 + +양자 공격은 Zcash나 Monero 같은 프라이버시 프로토콜에서 취약한 공개 키 방식으로 보호된 암호화 데이터를 노출시킬 수 있습니다. 금융 프로토콜의 P2P 통신을 복호화해 민감한 자산 정보를 드러내고 표적 도난을 가능하게 할 수도 있습니다. + +#### 04 - 해시 함수 역전 + +그로버 알고리즘은 작업 증명과 주소 생성에 쓰이는 SHA-256 등에 대한 원상(preimage) 공격을 가속할 수 있지만, 가장 덜 우려되는 위협입니다. 많은 포스트 퀀텀 암호 체계는 다이제스트가 충분히 크면 해시가 충분히 안전하다고 보는 해시 기반 구조를 포함합니다. + +### 포스트 퀀텀 암호화의 확장 과제 + +포스트 퀀텀 암호화(PQC)는 양자 위협에 대한 필수적 보호를 제공하지만, 이러한 알고리즘의 고유한 설계로 인해 상당한 확장 장애물을 만듭니다. 콤팩트한 수학 구조에 의존하는 타원곡선 방식과 달리, PQC 프리미티브는 고전·양자 공격자 모두에 대한 보안을 유지하려면 더 큰 매개변수가 필요합니다. 그 결과 공개 키·개인 키·서명이 종종 수배~수십 배 커집니다. 아래 표는 128비트 포스트 퀀텀 보안 수준에서 ML-DSA의 전형적인 크기와 256비트 ECDSA 등 고전 대응물을 비교한 것입니다. + + + +128비트 포스트 퀀텀 보안 수준에서의 크기. 출처: Open Quantum Safe Project + +보시다시피 ML-DSA 서명은 ECDSA 대응물보다 70배 이상 클 수 있고, 공개 키는 80배 이상 클 수 있습니다. 다른 PQC 계열은 더합니다: SPHINCS+ 같은 해시 기반 방식은 최대 41KB의 서명을 낼 수 있고, 크기 최적화 격자 변형인 FALCON도 여전히 고전 크기를 상당한 배수로 초과합니다. + +블록체인 맥락에서 이러한 팽창된 크기는 시스템적 확장 문제로 누적됩니다. 더 큰 서명은 개별 트랜잭션을 부풀려 블록이 더 빨리 차고 검증에 더 오래 걸리면서 초당 트랜잭션 수(TPS)를 낮춥니다. P2P 통신에도 부담을 주어 대역폭과 전파 지연이 늘고, 작업 증명 같은 합의에서 포크나 고아 블록 위험을 높일 수 있습니다. 저장 요구도 영향을 받아 노드 운영 비용이 오르고, 자원이 제한된 사용자나 검증자의 참여 장벽이 특히 커집니다. + + + 이러한 확장 과제는 앞으로 모든 블록체인이 다뤄야 합니다. 예를 들어 비트코인은 + 최대 블록 크기를 늘리지 않으면 1 TPS도 훨씬 못 미칠 것입니다. + + + + +### 조정 문제 + +비트코인의 보수적 문화는 프로토콜 변경에 저항합니다. 어떤 PQC 개선도 마이그레이션 기한, 가능한 몰수, 블록 크기 증대 같은 논쟁적 이슈에 대한 합의를 요구합니다. 커뮤니티가 합의하더라도 각 사용자는 자산을 양자 안전 주소로 옮겨야 합니다. 마이그레이션은 모든 암호화폐 보유자의 행동을 요구하는데, 많은 이가 지갑 접근을 잃었거나 위협을 모릅니다. + +이 문제는 모든 공개 블록체인에 있지만, 명확한 리더십 부재와 기술적 경화(osification) 철학 때문에 비트코인에 특히 어렵습니다. + +### 분실 코인 문제 + +비트코인 중 약 2,500억~5,000억 달러가 분실된 키, 사망한 보유자, 잊힌 지갑 등으로 영구적으로 접근 불가능한 것으로 추정됩니다. [3] 이 코인은 마이그레이션할 수 없으며, 암호학적으로 의미 있는 양자 컴퓨터(CRQC)를 만드는 공적 보상처럼 작동합니다. 양자 공격자는 마이그레이션되지 않은 공개 키에서 개인 키를 도출해 수십억 달러 규모의 BTC를 시장에 쏟아낼 가능성이 큽니다. + +> 유일한 기술적 해법은 마이그레이션되지 않은 코인을 동결하는 엄격한 기한을 두는 것인데, +> 이는 정치적으로 불가능합니다. + +그런 기한 없이는 마이그레이션되지 않은 코인이 털리고 매도되어 시장이 붕괴하고 네트워크 신뢰가 무너질 것입니다. + +### 마이그레이션 일정 문제 + +포스트 퀀텀 서명은 현재 비트코인 서명보다 20~80배 큽니다. 근본적인 아키텍처 변경 없이는 비트코인 성능이 이미 제한된 용량의 일부로 붕괴합니다. + +비트코인이 정치·기술적 과제를 해결한다고 가정해도, 마이그레이션 자체는 수개월~수년이 걸립니다. 각 보유자는 자금을 양자 안전 주소로 옮기기 위해 최소 한 번은 트랜잭션을 보내야 합니다. 많은 이가 먼저 시험 트랜잭션을 보낼 것입니다. 부풀려진 PQC 서명이 처리량을 질식시키면서, 네트워크는 취약한 코인이 여전히 노출된 채 수개월~수년간 이어지는 대기열에 직면합니다. + + + 이러한 누적 과제는 기존 체인에 양자 보안을 추가하는 일을 비현실적으로 어렵게 + 만듭니다. Quantus Network는 첫날부터 체인에 양자 보안을 통합해 이를 피합니다. + + + + +### 기초 + +Quantus Network는 이더리움과 폴카닷 뒤의 팀인 Parity Technologies가 개발한 블록체인 SDK인 Substrate 위에 구축되어 있습니다. Substrate는 매우 모듈화되어 있어 Quantus만의 차별점에 집중하도록 구성 요소를 쉽게 교체할 수 있습니다. + +Quantus는 Substrate를 다음과 같이 강화합니다. + +- 포스트 퀀텀 서명 체계 지원 추가 +- P2P 네트워크 보안을 포스트 퀀텀으로 업그레이드 +- 사용자 제어 가능한 트랜잭션 가역성 추가 +- 모든 데이터 타입을 필드 요소 한도에 맞춰 정렬해 데이터베이스를 ZK 친화적으로 구성 + +### 포스트 퀀텀 암호 프리미티브 + +Quantus Network는 NIST가 표준화한 PQC를 사용해 트랜잭션과 네트워크 통신이 양자 위협으로부터 안전하도록 합니다. 트랜잭션 무결성의 핵심은 **ML-DSA**(모듈-격자 기반 디지털 서명 알고리즘, 구 CRYSTALS-Dilithium)로, 보안·효율·구현 용이성의 균형으로 선택된 격자 기반 서명 방식입니다. ML-DSA는 모듈 격자상의 LWE(Learning With Errors)와 SIS(Short Integer Solution) 같은 문제의 난이도를 활용해 쇼어 알고리즘을 포함한 고전·양자 공격에 강한 저항을 제공합니다. + +트랜잭션 서명을 위해 Quantus는 **ML-DSA-87**을 통합합니다. 이는 NIST 보안 레벨 5(고전 256비트·양자 128비트에 해당)로 가장 높은 매개변수 세트로, 격자 암호분석의 잠재적 진전에 대비합니다. 격자 암호는 상대적으로 새롭고 실전 검증이 고전 방식보다 덜했기 때문에 이 선택은 신중함을 우선합니다. 더 큰 매개변수는 격자 암호분석의 잠재적 진전 위험을 완화하며, 더 작은 키 크기가 여전히 더 약한 표적이 될 수 있습니다. + +#### 검토한 대안 + +ML-DSA는 FN-DSA(Falcon) 같은 대안보다 선택되었는데, FN-DSA는 구현 복잡도가 더 높습니다(예: 블록체인에 부적합한 부동소수점 연산 필요), 사양에 결정적 키 생성이 없으며, 개발 당시 비최종 상태였습니다. + +SLH-DSA 같은 해시 기반 옵션은 서명이 더욱 커서(17KB 초과) 선택하지 않았습니다. 암호 민첩성(서명 체계 교체 능력)은 Substrate에 내장되어 있어, 향후 필요 시 이러한 대안을 비교적 쉽게 추가할 수 있습니다. + +ML-DSA-87은 더 큰 키와 서명을 만들지만, Quantus 초기 단계 네트워크에서는 저장이 아직 병목이 아니어서 관리 가능하며, 영지식 증명을 통한 웜홀 주소 등 최적화가 확장을 다룰 것입니다. + +구현 세부는 [QIP-0006](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0006.md)을 참고하세요. + +### LibP2P - 양자 의미에서 안전한 네트워크 + +Quantus Network는 피어 투 피어(P2P) 노드 간 통신을 ML-DSA로 인증하고 **ML-KEM**(모듈-격자 기반 키 캡슐화 메커니즘, 구 CRYSTALS-Kyber)으로 암호화해 보호합니다. 이 통합은 libp2p 스택까지 PQC를 확장하며, 양자 내성을 위해 핵심 구성을 수정합니다: 피어 신원에는 ML-DSA-87 서명, 전송 보안에는 ML-KEM-768(양자 내성 공유 비밀을 위한 추가 KEM 메시지로 Noise 핸드셰이크 확장). + +P2P 레이어는 양자 보안 분석에서 종종 간과됩니다. 피어 인증은 중요하지만, 피어 수준에서 공격자가 할 수 있는 최악은 노드를 사칭하고 무효 메시지를 보내 서비스 거부를 일으키는 것입니다. 블록체인 모델에서 노드는 보통 신뢰되지 않으며 공격이 감지되면 키를 쉽게 바꿀 수 있어 이미 완화됩니다. P2P 통신 복호화도 공격자에게 이익이 제한적입니다(예: 트랜잭션 경로 추적은 프록시나 Tor로 완화), 대부분의 데이터는 결국 온체인에서 공개됩니다. + +그럼에도 P2P 레이어를 양자 의미에서 안전하게 하면 도청, 중간자 공격, 양자 복호화로부터 보호되어 노드 가십, 블록 전파, 기타 네트워크 상호작용이 가까운 미래에도 기밀성과 무결성을 유지합니다. + +기술 세부는 [QIP-0004](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0004.md)를 참고하세요. + +### PQC 확장 - 웜홀 주소 + +포스트 퀀텀 암호화에 내재된 확장 과제를 다루기 위해 Quantus Network는 **「웜홀 주소(Wormhole Addresses)」**라 불리는 혁신적인 집계형 포스트 퀀텀 서명 방식을 도입합니다. 이 시스템은 Plonky2 증명 시스템(기본적으로 STARK)로 생성한 영지식 증명(ZKP)을 활용해 잔액 검증을 오프체인으로 옮겨, 체인이 개별 서명을 처리하지 않고 단일 컴팩트한 증명만 검증하게 합니다. 웜홀 주소는 하나의 증명으로 많은 트랜잭션을 검증할 수 있으며, 공개 입력(예: nullifier, 저장 루트, 출력 주소·금액)이 주된 제한 요인입니다. 이는 트랜잭션당 분할 저장 필요를 트랜잭션당 약 256바이트 추가 수준으로 줄여, 알려진 어떤 PQC 서명 방식보다 훨씬 작습니다. + +이 방식의 양자 보안은 SNARK에서 흔한 양자 취약 타원곡선 페어링 대신, FRI(Fast Reed-Solomon Interactive Oracle Proofs)를 통한 커밋에 안전한 해시 함수 **Poseidon2**를 쓰는 데서 옵니다. + +또한 인증 비밀은 Poseidon2 뒤에 숨겨집니다. 안전한 해시는 그로버에 의해 이차적으로만 약해지고 깨지지 않으므로, 해시 원상 증명은 SPHINCS+ 같은 해시 기반 방식과 유사하게 ZK 맥락에서 경량 포스트 퀀텀 서명 역할을 할 수 있습니다. + +#### 클라이언트 / 증명자 흐름 + +사용자는 솔트와 비밀을 이어붙인 값을 이중 해시해 이중 지불이 불가능함이 증명 가능한 주소를 만듭니다. + +``` +H(H(salt|secret)) +``` + +이 구조는 위양성(예: 단순 해시 공개 키를 소비 불가 주소와 혼동)을 막습니다. Substrate(및 일반적으로)에서 블록체인 주소는 안전한 해시가 아닌 대수 연산으로 개인 키에서 유도된 공개 키의 단순 해시이기 때문입니다. 구조의 보안은 안전한 해시의 이중 원상을 찾는 문제로 귀결됩니다. 이 주소로 보낸 토큰은 사실상 소각됩니다. 받은 주소에 대응하는 개인 키가 없어 지출할 수 없습니다. 이 코인은 공급을 늘리지 않고 재발행할 수 있습니다. + +각 전송마다 전역 고유 전송 횟수 등의 세부가 담긴 TransferProof 저장 객체가 생성됩니다. 사용자 지갑은 최근 블록 헤더의 저장 루트에서 이 TransferProof 리프까지의 머클-패트리시아 트라이(MPT) 저장 증명을 생성합니다. 이중 지불을 막기 위해 nullifier를 계산합니다. + +``` +H(H(salt | secret | global_transfer_count)) +``` + +#### 집계자 흐름 + +누구나(클라이언트, 채굴자, 제3자) Plonky2 재귀로 여러 증명을 집계해 부모가 자식을 검증하는 증명 트리를 만들 수 있으며, 자식의 공개 입력을 집계합니다. + +- nullifier는 그대로 전달 +- 출력 주소는 중복 제거 +- 블록 해시는 연결된 것으로 증명한 뒤 가장 최근 것만 남기고 폐기 +- 중복 출력 주소의 금액은 합산 + +#### 체인 / 검증자 흐름 + +네트워크는 집계 증명을 검증할 때 다음을 확인합니다: 블록 해시가 체인에 있고 최근인지, nullifier 고유성(이중 지불 방지), 증명 유효성. ZK 회로는 저장 증명의 정확성, nullifier 정확성, 주소의 소비 불가, 입출력 잔액 일치, 블록 헤더 연결을 강제합니다. + +#### Plonky2를 쓰는 이유 + +- 이미 감사됨 +- 포스트 퀀텀 +- 트러스티드 셋업 불필요 +- 증명·검증 효율적 +- 증명 집계가 자연스러움 +- Rust 네이티브 구현 +- Substrate의 no-std 환경과 호환 + + + 재귀 증명은 약 170밀리초에 끝나며 크기도 컴팩트합니다(집계 증명당 약 100KB). + 5MB 블록에 모든 트랜잭션이 동일 출력으로 가는 최적 경우, 웜홀 주소는 한 블록에 + 약 153,000건(nullifier당 32바이트로 4.9MB)을 담을 수 있어, 원시 ML-DSA 약 + 685건(5MB ÷ 7.3KB) 대비 약 223배 개선입니다. + + +#### 보안 참고 + +잠재적 위험에는 회로·검증 구현 결함으로 인한 인플레이션 버그가 있으나, 재발행 코인이 영 지갑 주소 잔액을 초과하면 경제적으로 드러납니다. 사용자는 비밀을 공개하지 않고 첫 해시만 공개해 웜홀 주소임을 선택적으로 증명할 수 있습니다. 검증 트랜잭션은 서명되지 않으므로 실패 트랜잭션에 의한 DoS는 금융 수단 없이 완화해야 합니다. 토큰 공급 계산은 유지되는데, 재발행은 새 코인처럼 보이지만 소각을 통해 최대 공급 보장이 유지됩니다. + +기술 세부는 [QIP-0005](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0005.md)를 참고하세요. + +### 합의 메커니즘 + +Quantus Network는 작업 증명(PoW) 합의 알고리즘을 사용하며, 비트코인 합의의 바람직한 성질을 유지하면서 SHA-256을 **Poseidon2**로 바꿔 ZK 증명 시스템과의 호환성을 높입니다. + +중요: 이 변경은 양자 보안 때문이 아닙니다. SHA-256 같은 암호학적 해시는 그로버 등 양자 알고리즘에 약해지지만 파괴되지는 않습니다. 일부 포스트 퀀텀 서명 방식은 이 이유로 안전한 해시를 기본 블록으로 씁니다. + +Poseidon2는 Poseidon 해시의 개선입니다. SHA-256 같은 전통 해시로 SNARK·STARK를 만들면 Poseidon을 쓸 때보다 게이트가 거의 100배 많이 필요한 경우가 많습니다. Poseidon은 비트 연산이 아닌 필드 원소에 대한 대수 함수에 전적으로 의존합니다. + +Poseidon2와 Plonky2에는 **골디락스(Goldilocks)** 필드를 사용합니다. 골디락스 필드의 차수는 부호 없는 64비트 정수에 들어가 효율을 높이면서도 견고함을 해치지 않습니다. + + + +암호화폐 키를 다룰 때의 위험은 많지만 대부분 피할 수 있습니다. + +### 가역 트랜잭션 + +Quantus Network는 사용자가 설정할 수 있는 가역 트랜잭션을 제공합니다. 발신자는 나가는 전송을 취소할 수 있는 시간 창을 둡니다. 이는 도난을 억제하고 실수를 바로잡으면서도 최종성을 희생하지 않습니다. 시스템은 타임스탬프가 있는 수정된 Substrate 「스케줄러」 팔렛을 사용합니다. 지갑은 발신자(취소 버튼 포함)와 수신자에게 카운트다운을 표시합니다. + +가역 트랜잭션은 온체인 적용을 통해 탈중앙성을 유지하면서 새로운 보안 프로토콜을 가능하게 합니다. + +기술 세부는 [QIP-0009](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0009.md)를 참고하세요. + +### 확인 문구 + +Quantus Network는 블록체인 주소에 대한 읽기 쉽고 암호학적으로 안전한 체크섬인 「check-phrases」를 도입합니다. 주소를 해시해 BIP-39 단어 목록에서 짧고 기억하기 쉬운 단어 열을 만듭니다. 확인 문구는 오타, 변조, 주소 중독 공격으로부터 보호합니다. 50,000회 반복의 키 유도 함수로 레인보우 테이블 공격 비용을 높입니다. 큰 거래에서는 여전히 주소의 모든 문자를 확인해야 합니다. + +기술 세부는 [QIP-0008](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0008.md)를 참고하세요. + +### 고보안 계정 + +모든 계정은 나가는 모든 전송에 필수 가역 기간을 두는 「고보안 계정」으로 승격할 수 있습니다. 지정된 **가디언**(하드웨어 지갑, 멀티시그, 신뢰 제3자)은 가역 기간 동안 의심스러운 트랜잭션을 취소해 자금을 발신자·수신자 대신 가디언에게 보낼 수 있습니다. 이 옵트인 기능은 한 번 활성화되면 영구적이라 도둑이 끌 수 없습니다. + +가디언은 연쇄될 수 있습니다: 고보안 계정의 가디언이 다시 고보안 계정이 되어 자체 가디언을 둘 수 있습니다. 이렇게 합성 가능한 계층이 생겨 각 가디언이 보호 대상 계정보다 상위 권한을 갖습니다. 설계는 합법적 전송의 최종성을 해치지 않으면서 사용자가 무단 활동을 발견하고 대응할 시간을 줍니다. + +기술 세부는 [QIP-0011](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0011.md)를 참고하세요. + +### 키 복구 + +많은 크립토 자산이 주인과 함께 묻혔습니다. Quantus Network는 고정 지연 후 언제든 자금을 인출할 수 있는 복구 주소를 간단히 지정하는 방법을 제공합니다. 그동안 소유자는 키에 접근할 수 있다면 복구를 거부할 수 있습니다. 이 기능은 생존을 가능하게 합니다: 법원이나 형식적 유산 없이 온체인 유언을 남길 수 있습니다. + +### HD-Lattice + +계층적 결정론적(HD) 지갑은 단일 시드 구문으로 모든 키를 백업해 수동 복사 대비 보안과 편의를 높이는 업계 표준입니다. Dilithium 같은 격자 방식에 맞추려면 두 가지 과제가 있습니다. + +- HMAC-SHA512 출력이 특정 성질을 가진 환에서 샘플링한 다항식인 격자 개인 키를 직접 구성할 수 없습니다. +- 비강화 키 유도는 타원곡선 덧셈에 의존하는데, 격자에는 그에 해당하는 대수 연산이 없습니다(공개 키가 어떤 연산에도 닫혀 있지 않음). + +Quantus Network는 첫 번째를 HMAC 출력을 키 자체가 아니라 개인 키를 결정적으로 구축하는 엔트로피로 쓰는 방식으로 다룹니다. 두 번째는 덜 치명적이며 격자 암호를 그에 맞게 조정할 수 있는지는 여전히 열린 연구 질문입니다. + +기술 세부는 [QIP-0002](https://github.com/Quantus-Network/improvement-proposals/tree/main/qip-0002)를 참고하세요. + + + +Quantus Network는 변화하는 환경에 있으며 처음부터 모두 맞출 수 있다고 가정하지 않습니다. 그래서 단순한 출발점을 택하고 새 정보가 쌓이면 거버넌스가 시스템을 바꿀 수 있게 했습니다. 이 설계는 블록체인을 환경에 적응할 수 있는 살아 있는 실체로 만듭니다. 특히 Substrate 거버넌스 프로세스는 노드 운영자 간 최소한의 조정으로도 체인에 깊은 변경을 허용합니다. + +### 블록 보상 + +Quantus Network는 비트코인을 본뜬 단순한 토크노믹스 모델을 씁니다. 최대 공급은 **2,100만 코인**이며, 간단한 휴리스틱이 블록 보상을 정합니다. + +``` +block_reward = (max_supply - current_supply) / constant +``` + +이 휴리스틱은 current_supply에 block_reward가 더해지면서 완만히 감소하는 지수 곡선을 이루고, 다음 블록에서 계산되는 block_reward를 줄입니다. 수수료 소각 등으로 current_supply가 줄면 그만큼 블록 보상 예산에 반영됩니다. 상수는 소각이 전혀 없을 때 약 30년 안에 코인의 99%가 발행되도록 선택됩니다. + +### 투자자 배분 + +Quantus Network는 자금을 넣으며 큰 위험을 감수한 투자자들의 도움으로 만들어졌습니다. 사모 투자자는 팀과 마찬가지로 4년 베스팅 일정이 적용됩니다. 공개 판매 투자자는 첫날부터 전액 유동성을 갖습니다. 공개 판매로 모은 자금은 토큰과 짝을 이루어 유동성(DEX, CEX, 마켓 메이커)에 사용됩니다. 이러한 투자자 배분과 유동성이 유일한 「프리마인」입니다. 나머지 토큰은 존재할 때까지 채굴로 나와야 합니다. + +공개 판매 최대 10% 미만이 팔리면 유동성 토큰은 비례해 줄고, 나머지는 블록 보상으로 채굴자에게 발행됩니다. + +### 회사 배분 + +새 기술을 성공 보장 없이 만들 위험을 감수한 팀에 보상하기 위해, 약 4년간 블록 보상의 일부가 회사로 갑니다. 이는 사실상 전체 공급의 약 **15%**에 해당하는 회사 베스팅 일정입니다. + +그 시점 이후 회사 몫은 끄거나 조정하거나 토큰 보유자 표결에 따라 재지향할 수 있습니다. + +### 트랜잭션 수수료 + + + +### 포크 없는 업그레이드 + +Quantus Network는 Substrate 런타임 업그레이드를 통해 「포크 없는」 업그레이드를 지원합니다. 블록체인 핵심 로직(「런타임」)이 네트워크를 어지럽히거나 커뮤니티를 쪼개는 하드 포크 없이 진화할 수 있습니다. 온체인 거버넌스 국민투표로 승인된 제안이 런타임 스왑을 켜며 — 기존 WASM 코드 블롭을 한 블록에서 새 것으로 바꿔 — 상태 연속성과 운영을 보장합니다. 이 경로는 다운타임과 위험을 줄이고, 실제 사용이 개선점을 드러내며 프로토콜을 반복적으로 다듬을 수 있게 합니다. + +커뮤니티가 시스템을 신뢰하게 되면 런타임 변경 권한은 악의적 행위자가 업데이트 과정을 장악할 경우 공격 표면을 줄이기 위해 크게 제한될 수 있습니다. + +### 거버넌스 시스템 + +Quantus Network는 Substrate를 통해 폴카닷의 OpenGov 시스템을 이어받습니다. 토큰 보유자는 **신념 투표(conviction voting)**로 참여하며, 자산을 기간 동안 잠가 표결 가중치를 높입니다. 증폭은 1x(잠금 없음)부터 6x(최대 잠금)까지 가능합니다. 이 설계는 참여에 영향을 가격으로 묶어 장기 정렬을 장려합니다. + +제안은 「오리진(origin)」이라 불리는 여러 투표 트랙으로 나뉩니다. 각 오리진은 맞춤 매개변수(예: 고영향 변경에는 초과 다수)와 스팸 방지 최소 예치금, 준비·집행 기간, 교착을 막는 결정 기한을 갖습니다. 이 다트랙 설계는 일상적 재정 지출부터 중요한 런타임 업그레이드까지 다양한 국민투표를 병렬로 처리합니다. + +**Technical Collective**는 긴급 기술 사안을 제안·검토·화이트리스트하는 큐레이션 전문가 그룹으로, 전용 트랙으로 속도를 내고 커뮤니티 감시를 유지합니다. + +Quantus는 이를 수정 없이 채택하되 초기에는 복잡도를 피하기 위해 미니멀 구성으로 시작합니다. 처음에는 Technical Collective 트랙만 활성화되어 프로토콜 업그레이드나 매개변수 조정 같은 고권한 결정에 쓰입니다. + +이후 Quantus는 집행 불가능한 주제(기능 제안, 생태계 설문 등)에 대한 비구속적 커뮤니티 투표 트랙을 추가할 수 있습니다. 회사가 네트워크를 DAO에 넘기면 이 시스템은 구속력을 갖게 됩니다. 이런 단계적 접근은 초기에 사용자에게 불필요한 복잡도를 지우지 않으면서 향후 거버넌스 표결로 유기적으로 진화할 수 있게 합니다. + + + +2026년까지의 현재 로드맵이며 변경될 수 있습니다. + + + + + + + + + + + + + + + +
    + + + +Quantus Network를 구축하는 데는 고유한 위험이 따릅니다. + +### 구현 문제 + +설계가 아무리 좋아도 소프트웨어 로직 결함은 심각한 장애를 일으킬 수 있습니다. + +### NIST 알고리즘 선택 문제 + +표준화 이후 ML-DSA, ML-KEM 등 선정된 포스트 퀀텀 표준에 결함이나 백도어가 드러날 수 있습니다. 최악의 경우 그런 결함으로 공개 키에서 개인 키를 도출해 서명을 위조할 수 있어 체인에 재앙적 고장 모드가 됩니다. 그런 결함이 공개되면 Quantus Network는 새 알고리즘으로 업그레이드할 수 있지만, 드물게 악용되면 영원히 발견되지 않을 수도 있습니다. + +### 양자 컴퓨팅 일정 + +양자 진전이 예상보다 훨씬 늦어 PQC 필요 시점이 늦춰질 수 있고, 반대로 정부 등의 비밀 개발은 블록체인 커뮤니티가 빠르게 업데이트하지 못하면 갑작스러운 위협이 될 수 있습니다. + +### 기타 고려 + +일반적인 채택 장벽, 금융·블록체인 규제 불확실성, 크립토 생태계 고유의 변동성. + + + +
    + + + Shor, P. W. (1997). Polynomial-time algorithms for prime factorization and + discrete logarithms on a quantum computer. _SIAM Journal on Computing_, 26(5), + 1484–1509. https://doi.org/10.1137/S0097539795293172 + + + + Grover, L.K. (1996). A fast quantum mechanical algorithm for database search. + _Proceedings of the Twenty-Eight Annual ACM Symposium on Theory of Computing_, + 212-219. https://doi.org/10.1145/237814.237866 + + + + Chainalysis. (2024). _The Chainalysis 2024 Crypto Crime Report_. + https://www.chainalysis.com/blog/2024-crypto-crime-report-introduction/ + + + + National Institute of Standards and Technology. (2024). _FIPS 204: + Module-Lattice-Based Digital Signature Standard (ML- DSA)_. U.S. Department of + Commerce. https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf + + + + National Institute of Standards and Technology. (2024). _FIPS 203: + Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)_. U.S. + Department of Commerce. + https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf + + + + Häner, T., Jaques, S., Naehrig, M., Roetteler, M., & Soeken, M. (2020). + Improved quantum circuits for elliptic curve discrete logarithms. + _arXiv:2002.12480_. https://arxiv.org/abs/2002.12480 + + + + Gidney, C., & Ekerå, M. (2021). _How to factor 2048 bit RSA integers in 8 + hours using 20 million noisy qubits_. _arXiv:1905.09749_. + https://arxiv.org/abs/1905.09749 + + + + Aggarwal, D., et al. (2021). Assessment of Quantum Threat To Bitcoin and + Derived Cryptocurrencies. _ePrint IACR_. https://eprint.iacr.org/2021/967.pdf + + + + Roetteler, M., Naehrig, M., Svore, K. M., & Lauter, K. (2017). Quantum + resource estimates for computing elliptic curve discrete logarithms. + _arXiv:1706.06752_. https://arxiv.org/abs/1706.06752 + + + + Open Quantum Safe Project. (n.d.). ML-DSA | Open Quantum Safe. Retrieved + January 29, 2026, from + https://openquantumsafe.org/liboqs/algorithms/sig/ml-dsa.html + diff --git a/website/src/contents/whitepapers/ru-RU/v0.3.3.mdx b/website/src/contents/whitepapers/ru-RU/v0.3.3.mdx new file mode 100644 index 0000000..5966b0f --- /dev/null +++ b/website/src/contents/whitepapers/ru-RU/v0.3.3.mdx @@ -0,0 +1,842 @@ +--- +title: "Quantus Network Whitepaper" +version: "0.3.3" +publishedDate: "2026-03-21" +updatedDate: "2026-03-21" +authors: ["Christopher Smith"] +changelog: + - "Крупная переработка: отказ от ответственности, содержание, нумерованные главы (01–09), обложка PDF, TOC; вместо заключения — «References & Further Reading»." + - "Новая глава: кризис миграции (координация, потерянные монеты, сроки PQC-миграции)." + - "Переписаны введение и раздел об угрозе: рамка CRQC, четыре нумерованные категории угроз, сноски в тексте." + - "Расширены или уточнены разделы об архитектуре и технике (Foundation/Substrate, LibP2P, wormhole/Plonky2, консенсус/поле Goldilocks)." + - "Дорожная карта: Bell Mainnet Q2 2026; Fermi Upgrade Q4 2026; в Planck Beta добавлена ZK-интеграция." +pdfCover: true +# В `render().headings` Astro не попадают JSX-`

    ` и ChapterHeading; slug якоря совпадает с id заголовков `###` в Markdown. +toc: + insertBefore: + квантовая-угроза: + - slug: legal-disclaimer + text: Юридическая информация + - slug: contents + text: Содержание + - slug: chapter-01 + text: Введение + основы-квантовых-вычислений: + - slug: chapter-02 + text: Квантовая угроза для блокчейна + проблема-координации: + - slug: chapter-03 + text: Кризис миграции + основы: + - slug: chapter-04 + text: Архитектура Quantus Network + обратимые-транзакции: + - slug: chapter-05 + text: Сохранение капитала + награды-за-блок: + - slug: chapter-06 + text: Токеномика и управление + ошибки-реализации: + - slug: chapter-07 + text: Дорожная карта + - slug: chapter-08 + text: Риски + insertAfter: + прочие-соображения: + - slug: chapter-09 + text: Ссылки и дополнительные материалы +--- + +import CalloutV2 from "@/components/features/whitepaper/mdx/CalloutV2.astro"; +import Figure from "@/components/features/whitepaper/mdx/Figure.astro"; +import Grid from "@/components/features/whitepaper/mdx/Grid.astro"; +import Column from "@/components/features/whitepaper/mdx/Column.astro"; +import TimelineV2 from "@/components/features/whitepaper/mdx/TimelineV2.astro"; +import ResponsiveTableV2 from "@/components/features/whitepaper/mdx/ResponsiveTableV2.astro"; +import SiteSocials from "@/components/ui/SiteSocials.astro"; +import OrderedList from "@/components/features/whitepaper/mdx/OrderedList.astro"; +import Divider from "@/components/features/whitepaper/mdx/Divider.astro"; +import ChapterHeading from "@/components/features/whitepaper/mdx/ChapterHeading.astro"; +import Reference from "@/components/features/whitepaper/mdx/Reference.astro"; +import ReferenceMarker from "@/components/features/whitepaper/mdx/ReferenceMarker.astro"; + +

    + +_Настоящий whitepaper предоставляется исключительно в информационных целях и +не является предложением о продаже, запросом предложения о покупке +или рекомендацией по любым ценным бумагам, инвестициям или финансовым +продуктам. Читателям следует самостоятельно провести должную проверку и +проконсультироваться с квалифицированными специалистами перед принятием инвестиционных решений. +Quantus Network не даёт заявлений и гарантий +относительно точности или полноты содержащейся здесь информации._ + +

    + Содержание +

    + + + +
    + + + +### Квантовая угроза + +Традиционные блокчейны сталкиваются с экзистенциальной угрозой со стороны +криптографически значимых квантовых компьютеров (CRQC). Криптографические основы блокчейнов опираются на сложность +задачи дискретного логарифмирования (DLP), а квантовые алгоритмы, +в частности алгоритм Шора, могут решать DLP экспоненциально быстрее, чем +классические компьютеры. Эта уязвимость может позволить квантовым +противникам выводить закрытые ключи из открытых, что даёт им +возможность подделывать транзакции и расшифровывать конфиденциальные финансовые +данные. + +> без упреждающих обновлений, устойчивых к квантовым вычислениям, криптоэкономика на триллионы долларов +> рискует внезапной девальвацией из‑за таких атак. + +### Уникальное ценностное предложение + +Названная по латинскому слову, означающему «сколько», Quantus Network +обеспечивает масштабируемые и квантово-безопасные частные деньги. Quantus — не +универсальная платформа смарт-контрактов. Как ресторан с небольшим меню +идеально отточенных блюд, Quantus предлагает: + +- Постквантовые подписи для всех транзакций +- Постквантовые подписи и шифрование (ML-DSA и ML-KEM) для защиты пиринговых соединений +- Постквантовые доказательства с нулевым разглашением для масштабирования +- Счета повышенной безопасности, чтобы сдерживать кражи и допускать исправление ошибок +- Читаемые контрольные фразы для простой проверки адресов + +Решение сфокусироваться на масштабируемых квантово-безопасных частных деньгах +обусловлено угрозой CRQC для отрасли и неспособностью Bitcoin +справиться с этими вызовами. + + + +### Основы квантовых вычислений + +Квантовые компьютеры используют такие принципы, как суперпозиция и +запутанность, чтобы выполнять вычисления, недоступные +классическим машинам. В отличие от классических битов, которые равны 0 или 1, +кубиты могут находиться в нескольких состояниях одновременно, +обеспечивая экспоненциальный параллелизм для ряда задач. Эта +способность создаёт экзистенциальные риски для криптографических систем, лежащих в основе +блокчейн-финансов: алгоритмы, разработанные для +квантового оборудования, подрывают предпосылки безопасности большей части +криптографии с открытым ключом. + +**Алгоритм Шора**, представленный в 1994 году Питером Шором, даёт +метод с полиномиальным временем работы для факторизации больших целых и решения +задачи дискретного логарифмирования на квантовом компьютере. Он опирается на +квантовые преобразования Фурье (QFT), чтобы находить период функции, +позволяя эффективно обращать односторонние функции с секретом, лежащие в основе +таких схем, как RSA или криптография на эллиптических кривых (ECC). Для +блокчейн-финансов это означает, что атакующий с достаточно мощным квантовым компьютером +(оценочно ~2000 логических кубитов ) +может выводить закрытые ключи из открытых за полиномиальное время O(n³): экстремальное ускорение, +которое делает уязвимые системы устаревшими за одну ночь. + +**Алгоритм Гровера**, предложенный Ловом Гровером в 1996 году, даёт +квадратичное ускорение для неструктурированного поиска, сокращая +время поиска с O(n) до O(√n) операций. Хотя он не столь +разрушителен, как Шор для асимметричной криптографии, Гровер +затрагивает симметричные примитивы — хеш-функции и шифрование AES, +фактически сокращая уровень безопасности вдвое (например, 256-битный ключ +ведёт себя как 128-битный против квантовых атак). Эту атаку +смягчают удвоением битовой стойкости, а не сменой +криптографической схемы. Кроме того, квадратичное ускорение Гровера мало применимо из‑за высоких требований к кубитам и гейтам: +нужны миллиарды последовательных операций при ограниченном параллелизме, +что делает его нереалистичным для практических взломов даже на +будущем оборудовании. + +### Четыре категории угроз + +#### 01 — Подделка цифровых подписей + +Алгоритм Шора напрямую угрожает подписям на основе ECC, используемым в +большинстве блокчейнов (например, кривая secp256k1 в Bitcoin), позволяя +противникам выдавать себя за пользователей и авторизовать +мошеннические транзакции. Такая возможность означала бы критический отказ +самой базовой функции блокчейна. + +#### 02 — Подделка ложных доказательств в системах с нулевым разглашением + +Многие доказательства с нулевым разглашением, например в zk-SNARKs для +финансов с упором на конфиденциальность, опираются на сложность дискретного логарифмирования через +спаривание на эллиптических кривых для обязательств. Шор может позволить +создавать недействительные доказательства, выглядящие действительными, что позволит атакующему чеканить новые монеты или фальсифицировать состояние L2. + +#### 03 — Расшифровка секретной информации + +Квантовые атаки могут раскрыть зашифрованные данные, защищённые +уязвимыми схемами с открытым ключом в протоколах конфиденциальности вроде Zcash +или Monero. Они также могут расшифровывать p2p-сообщения в финансовых +протоколах, раскрывая чувствительные сведения о капитале и позволяя целевые +кражи. + +#### 04 — Обращение хеш-функций + +Алгоритм Гровера может ускорить атаки на прообраз для хешей +вроде SHA-256, используемых в proof-of-work и генерации адресов, но +это наименее тревожная угроза. Многие постквантовые +схемы включают конструкции на основе хешей: хеши +считаются достаточно безопасными при достаточно большом размере дайджеста. + +### Проблемы масштабирования в постквантовой криптографии + +Хотя постквантовая криптография (PQC) даёт необходимую защиту +от квантовых угроз, она вносит серьёзные препятствия для масштабирования +из‑за самой природы этих алгоритмов. +В отличие от схем на эллиптических кривых, опирающихся на компактные математические структуры, +примитивы PQC требуют больших параметров, чтобы сохранять +стойкость против классических и квантовых противников. Отсюда +заметно большие открытые и закрытые ключи и подписи, +часто на порядки величины. Следующая таблица +иллюстрирует типичные размеры ML-DSA при уровне постквантовой безопасности 128 бит +в сравнении с классическими аналогами вроде 256-битного ECDSA: + + + +Размеры при уровне постквантовой безопасности 128 бит. Источник: Open +Quantum Safe Project + +Как видно, подписи ML-DSA могут быть более чем в 70 раз больше +эквивалентов ECDSA, а открытые ключи — более чем в 80 раз. +Другие семьи PQC усугубляют ситуацию: хешевые схемы вроде +SPHINCS+ могут давать подписи до 41 КБ, тогда как решёточные варианты, оптимизированные по размеру, +вроде FALCON, всё равно превосходят классические размеры +в несколько раз. + +В контексте блокчейна раздутые размеры складываются в +системные проблемы масштабирования. Более крупные подписи раздувают +отдельные транзакции, снижая TPS, так как блоки +заполняются быстрее и требуют больше времени на проверку. Также нагружается P2P-связь, растут пропускная способность и +задержки распространения, что может повышать риск форков или +осиротевших блоков в механизмах консенсуса вроде proof-of-work. +Требования к хранению тоже растут: выше операционные расходы узлов и барьеры к участию, особенно для +пользователей или валидаторов с ограниченными ресурсами. + + + Эти проблемы масштабирования в будущем придётся решать всем блокчейнам. У + Bitcoin, например, будет гораздо меньше 1 TPS, если не увеличивать + максимальный размер блока. + + + + +### Проблема координации + +Консервативная культура Bitcoin сопротивляется изменениям протокола. Любое улучшение PQC +потребовало бы консенсуса по спорным вопросам: сроки миграции, +возможная конфискация монет и увеличение размера блока. +Даже если сообщество согласится, каждому пользователю +пришлось бы переносить монеты на новые квантово-безопасные адреса. +Миграция требует действий всех держателей криптовалют, +многие из которых потеряли доступ к кошелькам или не осознают +угрозу. + +Эти проблемы есть у любой публичной блокчейн-сети, но для Bitcoin они особенно +сложны из‑за отсутствия ясного лидерства и +философии технического «окаменения». + +### Проблема потерянных монет + +Оценивается, что от 250 до 500 миллиардов долларов в Bitcoin +навсегда недоступны из‑за потерянных ключей, умерших владельцев или +забытых кошельков. [3] Эти монеты нельзя мигрировать: они действуют +как публичная награда за создание CRQC. Квантовые атакующие выведут закрытые ключи +из немигрированных открытых ключей и, вероятно, обрушат на рынок +миллиарды долларов в BTC. + +> единственное техническое решение — жёсткий срок, +> который замораживает немигрированные монеты: это +> политически невозможно. + +Без такого срока немигрированные монеты +будут украдены и проданы, обрушив рынок и разрушив +доверие к сети. + +### Проблема календаря миграции + +Постквантовые подписи в 20–80 раз больше текущих подписей Bitcoin. +Без фундаментальных архитектурных изменений производительность Bitcoin +рухнет до доли уже и так ограниченной пропускной способности. + +Даже если Bitcoin преодолеет политические и технические трудности, сама +миграция займёт месяцы или годы. Каждый владелец должен +отправить хотя бы одну транзакцию, чтобы перевести средства на квантово-безопасный адрес. +Многие сначала отправят пробные транзакции. Когда раздутые PQC-подписи душат пропускную способность, сеть сталкивается с очередью на +месяцы или годы, пока уязвимые к кванту монеты остаются под угрозой. + + + Эти накопленные вызовы делают чрезвычайно трудным добавление квантовой + безопасности к существующим цепям. Quantus Network избегает этого, встраивая + квантовую безопасность в цепь с первого дня. + + + + +### Основы + +Quantus Network построена на Substrate — SDK блокчейна, +разработанном Parity Technologies, командой за Ethereum и +Polkadot. Substrate высокомодулен: компоненты легко заменять, чтобы сфокусироваться на том, что делает Quantus уникальной. + +Quantus расширяет Substrate: + +- Добавляя поддержку постквантовых схем подписи +- Обновляя безопасность P2P-сети до постквантовой +- Добавляя управляемую пользователем обратимость транзакций +- Делая базу данных совместимой с zk, выравнивая все типы данных с + границами элементов поля + +### Постквантовые криптографические примитивы + +Quantus Network использует PQC, стандартизированную NIST, чтобы обеспечить +безопасность транзакций и сетевого взаимодействия против +квантовых угроз. В основе целостности транзакций — **ML-DSA** +(алгоритм цифровой подписи на модульных решётках, ранее +CRYSTALS-Dilithium) — схема подписи на решётках, выбранная за баланс безопасности, эффективности и простоты +реализации. ML-DSA опирается на сложность задач вроде +Learning With Errors (LWE) и Short Integer Solution (SIS) на модульных +решётках, обеспечивая устойчивость к классическим и +квантовым атакам, включая алгоритм Шора. + +Для подписей транзакций Quantus внедряет **ML-DSA-87** — набор параметров +с наивысшим уровнем безопасности (уровень 5 NIST, +эквивалент 256 битам классической и 128 битам квантовой стойкости), +чтобы защититься от возможных прорывов в криптоанализе решёток. Этот выбор отдаёт приоритет осторожности: криптография на решётках относительно нова и менее проверена в бою, чем классические схемы. +Более крупные параметры снижают риски потенциальных успехов +в криптоанализе решёток, при которых меньшие ключи +остались бы более слабой мишенью. + +#### Рассмотренные альтернативы + +ML-DSA выбран вместо альтернатив вроде FN-DSA (Falcon) из‑за большей сложности реализации FN-DSA (например, требуются +операции с плавающей запятой, неудобные для блокчейна), отсутствия +детерминированной генерации ключей в спецификации и незавершённого +статуса на момент разработки. + +Хешевые варианты вроде SLH-DSA не выбраны из‑за ещё больших +подписей (свыше 17 КБ). Крипто-гибкость +(возможность менять схему подписи) встроена в +Substrate, поэтому добавить эти альтернативы в +будущем относительно просто, если потребуется. + +Хотя ML-DSA-87 даёт более крупные ключи и подписи, они +управляемы на ранней стадии сети Quantus, где хранение ещё не +узкое место, а оптимизации вроде wormhole-адресов через +доказательства с нулевым разглашением решат проблему масштабирования. + +Технические детали реализации см. в [QIP-0006](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0006.md). + +### LibP2P — квантово-безопасная сеть + +Quantus Network защищает обмен между узлами peer-to-peer (P2P), +сочетая ML-DSA для аутентификации +и **ML-KEM** (механизм инкапсуляции ключей на модульных решётках, +ранее CRYSTALS-Kyber) для шифрования. Эта интеграция распространяет PQC на стек libp2p, изменяя +ключевые компоненты для квантовой стойкости: подписи ML-DSA-87 +для идентичности пиров и ML-KEM-768 для безопасности транспорта +(расширение рукопожатия Noise дополнительным KEM-сообщением +для общих секретов, устойчивых к кванту). + +P2P-уровень часто упускают в анализе квантовой безопасности. +Аутентификация пиров важна, но худшее, что может сделать атакующий +на уровне пиров, — выдать себя за узел и слать недействительные +сообщения, что может вызвать отказ в обслуживании. Это уже +смягчается тем, что узлы в модели блокчейна обычно не доверяют +и могут легко сменить ключ при обнаружении атаки. Расшифровка P2P +даёт атакующему ограниченную пользу (например, отслеживание путей транзакций, +смягчается прокси или Tor), а большая часть данных всё равно становится публичной в +цепи. + +Тем не менее квантово-безопасный P2P защищает от +прослушки, атак «человек посередине» и квантового +расшифрования, гарантируя, что gossip узлов, распространение блоков и +другие сетевые взаимодействия остаются конфиденциальными и целостными в +обозримом будущем. + +Технические детали см. в [QIP-0004](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0004.md). + +### Масштабирование PQC — wormhole-адреса + +Чтобы справиться с проблемами масштабирования постквантовой +криптографии, Quantus Network вводит инновационную агрегированную постквантовую схему подписи под названием **«Wormhole Addresses»**. +Она использует доказательства с нулевым разглашением (ZKP), +генерируемые системой доказательств Plonky2 (по сути STARK), чтобы +вынести проверку балансов за пределы цепи, позволяя цепи проверять +одно компактное доказательство без обработки отдельных подписей. +Wormhole Addresses позволяют верифицировать большое число +транзакций одним доказательством; публичные входы (например, nullifier, +корень хранилища, выходные адреса и суммы) — главный +ограничивающий фактор. Это снижает амортизированные потребности в хранении на транзакцию +до примерно 256 дополнительных байт на транзакцию — +намного меньше, чем у любой известной схемы PQC-подписи. + +Квантовая безопасность схемы обеспечивается использованием стойкой хеш-функции +**Poseidon2** для обязательств через FRI (Fast +Reed-Solomon Interactive Oracle Proofs) вместо привычных для SNARK +уязвимых к кванту спариваний на эллиптических кривых. + +Кроме того, секреты аутентификации скрыты за +Poseidon2. Поскольку стойкие хеш-функции ослабляются только квадратично +алгоритмом Гровера, они не «ломаются»; доказательства прообраза для хеша +могут служить лёгкими постквантовыми подписями в ZK-контекстах, +аналогично хешевым схемам вроде SPHINCS+. + +#### Поток клиент / доказывающая сторона + +Пользователи генерируют доказуемо нерасходуемый адрес двойным хешированием соли, +сконкатенированной с секретом: + +``` +H(H(salt|secret)) +``` + +Эта конструкция исключает ложные срабатывания (например, путаница простого хеш-ключа +с нерасходуемым адресом): в Substrate +(и вообще) блокчейн-адреса — это простой хеш +открытого ключа, полученного из закрытого через алгебраическую операцию, +а не стойкий хеш. Безопасность конструкции +сводится к поиску прообраза-прообраза стойкого +хеша. Токены, отправленные на этот адрес, фактически сжигаются. +Их нельзя потратить: для адреса-получателя нет закрытого ключа. +Эти монеты можно снова отчеканить +без инфляции предложения. + +Для каждого перевода создаётся объект хранилища TransferProof +с деталями вроде глобального счётчика переводов. Кошелёк пользователя +генерирует доказательство Merkle-Patricia-Trie (MPT) от +корня хранилища недавнего заголовка блока до листа этого TransferProof. +Вычисляется nullifier, чтобы предотвратить двойной расход: + +``` +H(H(salt | secret | global_transfer_count)) +``` + +#### Поток агрегатора + +Любая сторона (клиент, майнер или третье лицо) может агрегировать несколько +доказательств через рекурсию Plonky2, формируя дерево доказательств, где +каждое родительское доказывает дочерние, агрегируя публичные входы детей: + +- Nullifier проходят без изменений +- Выходные адреса дедуплицируются +- Хеши блоков доказываются связанными, затем отбрасываются кроме последнего +- Суммы для дублирующихся выходных адресов суммируются + +#### Поток цепь / верификатор + +Сеть проверяет агрегированное доказательство: хеш блока +в цепи и недавний, уникальность nullifier (против двойного +расхода) и валидность доказательства. ZK-схема обеспечивает корректность доказательства хранилища, +точность nullifier, нерасходуемость адреса, +согласованность балансов входов и выходов и +связь заголовков блоков. + +#### Почему Plonky2 + +- Уже проходил аудит +- Постквантовый +- Без trusted setup +- Эффективное доказательство/верификация +- Плавная агрегация доказательств +- Нативная реализация на Rust +- Совместим с no-std окружением Substrate + + + Рекурсивные доказательства завершаются за 170 миллисекунд при компактных + размерах (100 КБ на агрегированное доказательство). В оптимальном случае с + блоками 5 МБ и всеми транзакциями на один выход wormhole-адреса могли бы + упаковать ~153 000 транзакций в один блок (4,9 МБ / 32 байта на nullifier): + улучшение в 223 раза по сравнению с ~685 «сырыми» транзакциями ML-DSA (5 МБ / + 7,3 КБ каждая). + + +#### Замечания по безопасности + +Потенциальные риски включают ошибки инфляции из-за дефектов схемы/верификатора, +хотя они будут экономически заметны, если +перечеканенные монеты превысят балансы с нулевых адресов отправки. Пользователи +могут по желанию доказать, что адрес — wormhole, опубликовав +первый хеш без раскрытия секрода. Проверочные транзакции не +подписаны, поэтому DoS из-за неудачных транзакций нужно +смягчать без финансовых рычагов. Расчёты предложения токенов +сохраняются: перечеканка выглядит как новые монеты, но сохраняет +гарантии максимального предложения за счёт сжиганий. + +Подробнее см. [QIP-0005](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0005.md). + +### Механизм консенсуса + +Quantus Network использует алгоритм консенсуса Proof-of-Work (PoW), +сохраняющий желаемые свойства консенсуса Bitcoin +и улучшающий совместимость с ZK-доказательствами, заменяя +SHA-256 на **Poseidon2**. + +Важно: это изменение сделано не ради квантовой безопасности. +Криптографические хеш-функции вроде SHA-256 ослабляются, но не уничтожаются +квантовыми алгоритмами, в частности Гровером. Некоторые постквантовые схемы подписи +используют стойкие хеши как строительный блок +по этой причине. + +Poseidon2 — усовершенствование хеш-функции Poseidon. Создание +SNARK или STARK для вычислений с традиционными хешами +вроде SHA-256 обычно требует почти в 100 раз больше +гейтов, чем с Poseidon, который целиком опирается на +алгебраические операции над элементами поля, а не на побитовые операции. + +Для Poseidon2 и Plonky2 используется **поле Goldilocks**. Порядок +поля Goldilocks помещается в 64-битное беззнаковое целое, что +повышает эффективность без ущерба для стойкости. + + + +При управлении ключами криптовалют существует много рисков. Большинство +из них можно избежать. + +### Обратимые транзакции + +Quantus Network предлагает настраиваемые пользователем обратимые транзакции. +Отправители задают временное окно, в котором могут отменить исходящие +переводы. Это сдерживает кражи и исправляет ошибки без потери +финальности. Система использует модифицированный pallet Substrate «scheduler» +с метками времени. Кошельки показывают обратный отсчёт отправителю +(с кнопкой отмены) и получателю. + +Обратимые транзакции позволяют новые протоколы безопасности, сохраняя +децентрализацию через исполнение в цепи. + +Подробнее см. [QIP-0009](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0009.md). + +### Контрольные фразы + +Quantus Network вводит «check-phrases» — читаемую человеком криптографически +стойкую контрольную сумму для блокчейн-адреса. Адрес хешируется, чтобы получить короткую последовательность запоминающихся слов +из списка BIP-39. Контрольные фразы защищают +от опечаток, подмены и атак отравления адресов. Функция вывода ключа с 50 000 итераций +делает атаки радужных таблиц дорогими. Для крупных транзакций пользователи всё равно должны проверять каждый +символ адреса. + +Технические детали см. в [QIP-0008](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0008.md). + +### Счета повышенной безопасности + +Любой счёт можно улучшить до «счёта повышенной безопасности» с +обязательными периодами обратимости для всех исходящих переводов. Назначенный **опекун** +(аппаратный кошелёк, мультисиг или доверенное третье лицо) может +отменять подозрительные транзакции в период обратимости, переводя +средства опекуну вместо отправителя или получателя. Эта опция необратима после включения: воры не смогут её отключить. + +Опекуны можно выстраивать в цепочку: опекун счёта повышенной безопасности может +сам быть счётом повышенной безопасности со своим опекуном. Так возникают +композитные иерархии, где у каждого опекуна есть более высокие полномочия +над защищаемым счётом. Дизайн даёт время обнаружить и отреагировать на несанкционированную активность без +компромисса финальности легитимных переводов. + +Подробнее см. [QIP-0011](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0011.md). + +### Восстановление ключей + +Многие крипто-состояния ушли в могилу вместе с владельцами. +Quantus Network даёт простой способ указать адрес восстановления, +который может вывести средства в любой момент после фиксированной задержки. В течение +этого времени владелец может отклонить восстановление, если имеет доступ к +ключу. Эта функция обеспечивает «выживание»: у пользователей есть завещание в цепи +без судов и формального наследования. + +### HD-Lattice + +Иерархические детерминированные (HD) кошельки — отраслевой стандарт +для блокчейнов: одна seed-фраза для всех +ключей, выше безопасность и удобство по сравнению с ручным копированием на +каждое действие. Адаптация к решёточным схемам вроде Dilithium ставит две +задачи: + +- Выходы HMAC-SHA512 не могут напрямую формировать решёточные закрытые ключи, + которые представляют собой полиномы, выбранные из кольца с определёнными + свойствами. +- Неусиленная деривация ключей опирается на сложение на эллиптических кривых, + отсутствующее на решётках (открытые ключи не замкнуты ни под какой алгебраической операцией). + +Quantus Network решает первый пункт, используя выход +HMAC как энтропию для детерминированного построения закрытого ключа, +а не как сам ключ. Второй пункт менее критичен и +остаётся открытым вопросом исследований — можно ли адаптировать решёточную криптографию +для его решения. + +Подробнее см. [QIP-0002](https://github.com/Quantus-Network/improvement-proposals/tree/main/qip-0002). + + + +Quantus Network существует в меняющейся среде, и мы не можем +предполагать, что всё сделаем с первого раза. Поэтому выбрана +простая отправная точка, а система управления +может вносить изменения по мере поступления новой информации. Такой дизайн превращает блокчейн в живую сущность, способную +подстраиваться к окружению. В частности, процесс управления Substrate +позволяет глубокие изменения цепи при минимальной координации +между операторами узлов. + +### Награды за блок + +Quantus Network использует простую токеномику по образцу +Bitcoin. Максимальное предложение — **21 000 000 монет**, а простая эвристика +определяет награду за блок: + +``` +block_reward = (max_supply - current_supply) / constant +``` + +Эта эвристика образует плавно убывающую экспоненциальную кривую: по мере того как +block_reward увеличивает current_supply, уменьшается +рассчитанная block_reward в следующем блоке. Сжигания комиссий и +другие уменьшения current_supply снова входят в +бюджет наград за блок. Константа подобрана так, что без +сжиганий 99% монет выпускается примерно за 30 +лет. + +### Распределение инвесторам + +Quantus Network создавалась с помощью инвесторов, взявших на себя +большой риск финансирования. Частные инвесторы подлежат графику вестинга 4 года, +как и команда. Инвесторы публичной продажи получат полную ликвидность в первый день. Средства публичной продажи будут +сопоставлены с токенами и направлены на ликвидность (DEX, CEX и маркет-мейкеры). Эти распределения инвесторам вместе с ликвидностью составят +единственный «премайн». Остальные токены должны быть добыты майнингом до +исчерпания предложения. + +Если в ходе публичной продажи будет продано меньше максимальных 10%, +токены ликвидности будут пропорционально уменьшены, а остаток будет выпущен майнерам через награды за блок. + +### Распределение компании + +Чтобы вознаградить команду за риск создания новой технологии +без гарантии успеха, часть награды за блок направляется компании +около четырёх лет. Это фактически график вестинга примерно **15% от общего предложения** для компании. + +После этого долю компании в наградах за блок можно +отключить, скорректировать или перенаправить по голосованию держателей токенов. + +### Комиссии транзакций + + + +### Обновления без форка + +Quantus Network поддерживает обновления «без форка» через +обновления runtime в Substrate: основная логика блокчейна +(«runtime») может эволюционировать без хард-форков, нарушающих +сеть или разделяющих сообщество. Это достигается референдумами управления в цепи: одобренные предложения активируют смену runtime +— по сути замену существующего WASM-блоба новым +в одном блоке с сохранением состояния и +операций. Такой путь минимизирует простои и риски, +давая сообществу итеративно улучшать протокол по мере того, как реальное использование выявляет улучшения. + +По мере роста доверия к системе +возможность менять runtime будет существенно ограничена, чтобы снизить +поверхность атаки, если злоумышленник получит контроль над +процессом обновления. + +### Система управления + +Quantus Network наследует рамку управления из +системы OpenGov Polkadot через Substrate. Держатели токенов +участвуют через **голосование с убеждением (conviction voting)**, блокируя +активы на разные сроки, чтобы усилить вес голоса. Усиление может быть от 1× (без блокировки) до 6× (максимальная блокировка). +Такой дизайн поощряет долгосрочное выравнивание интересов, связывая влияние с +обязательством. + +Предложения распределяются по нескольким трекам голосования — +«origins». У каждого origin свои параметры: пороги одобрения +(например, квалифицированное большинство для высокоинвазивных изменений), минимальные депозиты против спама, периоды подготовки/исполнения и +сроки решения, чтобы избежать тупиков. Многотрековый дизайн +позволяет параллельно обрабатывать разные референдумы — от рутинных трат казны +до критических обновлений runtime. + +**Technical Collective** — курируемая группа технических экспертов, +выступающая специализированным органом для предложения, ревью или внесения в белый список срочных технических вопросов, +ускоряя их по выделенному треку при сохранении надзора сообщества. + +Quantus принимает эту систему без изменений, но начинает с +минималистичной конфигурации, чтобы избежать сложности на ранних этапах. Изначально +активен только трек Technical Collective для +обязательных решений высокого уровня вроде обновлений протокола или +корректировки параметров. + +Позже Quantus может добавить трек некоммьюнити-голосования без обязательной силы для +опроса настроений по необязательным темам — предложения функций +или опросы экосистемы. Эта система станет обязательной, +когда компания передаст сеть DAO. Поэтапный подход +позволяет сети органично развиваться будущими голосованиями управления +без перегрузки пользователей сложностью в начале. + + + +Текущая дорожная карта до 2026 года, может меняться. + + + + + + + + + + + + + + + +
    + + + +Создание Quantus Network сопряжено с присущими рисками. + +### Ошибки реализации + +Дефекты в логике ПО могут вызывать серьёзные сбои даже в лучше всего +спроектированных системах. + +### Риски выбора алгоритмов NIST + +Дефекты или потенциальные бэкдоры в выбранных постквантовых стандартах +(например, ML-DSA, ML-KEM), которые могут проявиться после стандартизации. В худшем +случае такие дефекты позволят атакующему подделывать +подписи, выводя закрытый ключ из открытого — это +катастрофический режим отказа цепи. Если такие дефекты станут публичными, Quantus Network сможет обновиться на новый алгоритм, +но при редкой эксплуатации они могут так и не быть +обнаружены. + +### Сроки квантовых вычислений + +Квантовый прогресс может наступить гораздо позже прогнозов, +откладывая необходимость PQC; наоборот, секретная разработка (например +государствами) может создать внезапные угрозы, если блокчейн-сообщество +не обновится быстро. + +### Прочие соображения + +Общие барьеры внедрения, регуляторная неопределённость в +финансах/блокчейне и присущая криптоэкосистемам волатильность. + + + +
    + + + Shor, P. W. (1997). Polynomial-time algorithms for prime factorization and + discrete logarithms on a quantum computer. _SIAM Journal on Computing_, 26(5), + 1484–1509. https://doi.org/10.1137/S0097539795293172 + + + + Grover, L.K. (1996). A fast quantum mechanical algorithm for database search. + _Proceedings of the Twenty-Eight Annual ACM Symposium on Theory of Computing_, + 212-219. https://doi.org/10.1145/237814.237866 + + + + Chainalysis. (2024). _The Chainalysis 2024 Crypto Crime Report_. + https://www.chainalysis.com/blog/2024-crypto-crime-report-introduction/ + + + + National Institute of Standards and Technology. (2024). _FIPS 204: + Module-Lattice-Based Digital Signature Standard (ML- DSA)_. U.S. Department of + Commerce. https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf + + + + National Institute of Standards and Technology. (2024). _FIPS 203: + Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)_. U.S. + Department of Commerce. + https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf + + + + Häner, T., Jaques, S., Naehrig, M., Roetteler, M., & Soeken, M. (2020). + Improved quantum circuits for elliptic curve discrete logarithms. + _arXiv:2002.12480_. https://arxiv.org/abs/2002.12480 + + + + Gidney, C., & Ekerå, M. (2021). _How to factor 2048 bit RSA integers in 8 + hours using 20 million noisy qubits_. _arXiv:1905.09749_. + https://arxiv.org/abs/1905.09749 + + + + Aggarwal, D., et al. (2021). Assessment of Quantum Threat To Bitcoin and + Derived Cryptocurrencies. _ePrint IACR_. https://eprint.iacr.org/2021/967.pdf + + + + Roetteler, M., Naehrig, M., Svore, K. M., & Lauter, K. (2017). Quantum + resource estimates for computing elliptic curve discrete logarithms. + _arXiv:1706.06752_. https://arxiv.org/abs/1706.06752 + + + + Open Quantum Safe Project. (n.d.). ML-DSA | Open Quantum Safe. Retrieved + January 29, 2026, from + https://openquantumsafe.org/liboqs/algorithms/sig/ml-dsa.html + diff --git a/website/src/contents/whitepapers/zh-CN/v0.3.3.mdx b/website/src/contents/whitepapers/zh-CN/v0.3.3.mdx new file mode 100644 index 0000000..1f73b14 --- /dev/null +++ b/website/src/contents/whitepapers/zh-CN/v0.3.3.mdx @@ -0,0 +1,690 @@ +--- +title: "Quantus Network Whitepaper" +version: "0.3.3" +publishedDate: "2026-03-21" +updatedDate: "2026-03-21" +authors: ["Christopher Smith"] +changelog: + - "大幅修订:法律免责声明、目录、编号章节(01–09)、PDF 封面、TOC;用「参考文献与延伸阅读」替代结束语。" + - "新章节:迁移危机(协调问题、丢失代币、PQC 迁移时间线)。" + - "引言与量子威胁章节重写:CRQC 表述、四类编号威胁、文内引用。" + - "架构与技术章节扩充或澄清(Foundation/Substrate、LibP2P、wormhole/Plonky2、共识/Goldilocks 域)。" + - "路线图:Bell 主网 Q2 2026;Fermi 升级 Q4 2026;Planck Beta 增加 ZK 集成。" +pdfCover: true +# Astro `render().headings` 不会包含 JSX `

    ` 与 ChapterHeading;锚点 slug 与 Markdown `###` 的 id 一致。 +toc: + insertBefore: + 量子威胁: + - slug: legal-disclaimer + text: 法律声明 + - slug: contents + text: 目录 + - slug: chapter-01 + text: 引言 + 量子计算基础: + - slug: chapter-02 + text: 区块链面临的量子威胁 + 协调问题: + - slug: chapter-03 + text: 迁移危机 + 基础: + - slug: chapter-04 + text: Quantus Network 架构 + 可逆交易: + - slug: chapter-05 + text: 财富保全 + 区块奖励: + - slug: chapter-06 + text: 代币经济学与治理 + 实现问题: + - slug: chapter-07 + text: 路线图 + - slug: chapter-08 + text: 风险 + insertAfter: + 其他考量: + - slug: chapter-09 + text: 参考文献与延伸阅读 +--- + +import CalloutV2 from "@/components/features/whitepaper/mdx/CalloutV2.astro"; +import Figure from "@/components/features/whitepaper/mdx/Figure.astro"; +import Grid from "@/components/features/whitepaper/mdx/Grid.astro"; +import Column from "@/components/features/whitepaper/mdx/Column.astro"; +import TimelineV2 from "@/components/features/whitepaper/mdx/TimelineV2.astro"; +import ResponsiveTableV2 from "@/components/features/whitepaper/mdx/ResponsiveTableV2.astro"; +import SiteSocials from "@/components/ui/SiteSocials.astro"; +import OrderedList from "@/components/features/whitepaper/mdx/OrderedList.astro"; +import Divider from "@/components/features/whitepaper/mdx/Divider.astro"; +import ChapterHeading from "@/components/features/whitepaper/mdx/ChapterHeading.astro"; +import Reference from "@/components/features/whitepaper/mdx/Reference.astro"; +import ReferenceMarker from "@/components/features/whitepaper/mdx/ReferenceMarker.astro"; + +

    + +_本白皮书仅供信息参考, +不构成出售要约、购买要约招揽, +或对任何证券、投资或金融产品的推荐。读者在做出投资决策前应自行尽职调查, +并咨询合格专业人士。 +Quantus Network 不对本文所含信息的准确性或完整性作出任何陈述或保证。_ + +

    + 目录 +

    + + + +
    + + + +### 量子威胁 + +传统区块链面临来自 +密码学相关量子计算机(CRQC)的生存威胁。区块链的 +密码学基础依赖于 +离散对数问题(DLP)的难度,而量子算法, +尤其是 Shor 算法,可以以指数级快于 +经典计算机的速度求解 DLP。这一漏洞可能使量子 +对手从公钥推导出私钥,从而 +伪造交易并解密敏感的金融 +数据。 + +> 若无主动的抗量子升级,数万亿美元的加密经济 +> 可能因此类攻击而突然贬值。 + +### 独特价值主张 + +Quantus Network 以拉丁语中表示「多少」的词命名, +提供可扩展、量子安全的隐私货币。Quantus 不是通用 +智能合约平台。如同一家只提供少数几道 +精心打磨菜品的餐厅,Quantus 提供: + +- 所有交易均采用后量子签名 +- 后量子签名与加密(ML-DSA 与 ML-KEM)保护对等节点连接 +- 后量子零知识证明以实现扩展 +- 高安全性账户以遏制盗窃并支持从错误中恢复 +- 可读校验短语,便于简单验证地址 + +聚焦可扩展、量子安全的隐私货币这一决策, +源于 CRQC 对行业的威胁,以及比特币 +无力应对这些挑战。 + + + +### 量子计算基础 + +量子计算机利用叠加与 +纠缠等原理,执行对 +经典机器而言难以处理的计算。与只能为 0 或 1 的经典比特不同, +量子比特(qubits)可同时处于多种状态, +为特定问题带来指数级并行。这一 +能力对支撑区块链金融的密码系统构成生存风险,因为为 +量子硬件开发的算法动摇了大多数 +公钥密码学的安全假设。 + +**Shor 算法**由 Peter Shor 于 1994 年提出,在量子计算机上为分解大整数和求解 +离散对数问题提供 +多项式时间方法。它利用量子 +傅里叶变换(QFT)寻找函数的周期, +从而高效逆转支撑 +RSA 或椭圆曲线密码(ECC)等方案的陷门函数。对区块链 +金融而言,这意味着拥有足够强大的量子计算机(估计约 2,000 个逻辑量子比特 ) +的攻击者可在多项式时间 O(n³) 内从公钥推导私钥:极端的加速 +使脆弱系统一夜之间过时。 + +**Grover 算法**由 Lov Grover 于 1996 年提出,为非结构化搜索提供 +平方加速,将搜索时间从 O(n) 降至 O(√n) 次操作。虽不如 +Shor 对非对称密码那样致命,Grover +仍影响哈希函数与 AES 加密等对称原语, +实质上使安全级别减半(例如 256 位密钥 +在量子攻击下表现得像 128 位)。该攻击通过 +将安全位数加倍而非更换 +密码方案来缓解。此外,Grover 的平方加速因极高的量子比特与门需求而在实践中难以落地, +需要数十亿次顺序操作且并行度有限, +即便在未来硬件上,对现实世界的逆向仍不经济。 + +### 四类威胁 + +#### 01 - 伪造数字签名 + +Shor 算法直接威胁大多数区块链使用的基于 ECC 的签名 +(例如比特币的 secp256k1 曲线),使 +对手可冒充用户并授权欺诈 +交易。这种能力将构成区块链 +最基本功能的灾难性失效。 + +#### 02 - 在零知识系统中伪造无效证明 + +许多零知识证明,例如面向隐私金融的 zk-SNARKs, +依赖椭圆曲线配对实现的离散对数难度来承诺。Shor 可能允许 +创建看似有效实则无效的证明,使攻击者可铸造新币或伪造 Layer 2(L2)状态。 + +#### 03 - 解密秘密信息 + +量子攻击可能暴露 Zcash +或 Monero 等隐私协议中受脆弱公钥方案保护的加密数据;也可能解密金融协议中的 p2p 通信, +泄露敏感财富细节并促成定向盗窃。 + +#### 04 - 逆向哈希函数 + +Grover 算法可加速对 SHA-256 等哈希的原像攻击(用于工作量证明与地址生成),但 +这是最不令人担忧的威胁。许多后量子 +密码方案采用基于哈希的构造,因为只要摘要足够大, +哈希仍被认为足够安全。 + +### 后量子密码中的扩展挑战 + +尽管后量子密码(PQC)为抵御 +量子威胁提供必要保护,但由于这些算法的固有设计, +会引入显著的扩展障碍。 +与依赖紧凑数学结构的椭圆曲线方案不同, +PQC 原语需要更大参数以维持对经典与量子 +对手的安全性。这导致公钥、私钥与签名明显更大, +往往相差数个数量级。下表 +展示 128 位后量子安全级别下 ML-DSA 的典型规模, +相对 256 位 ECDSA 等经典等价物: + + + +128 位后量子安全级别下的规模。来源:Open +Quantum Safe Project + +可见,ML-DSA 签名可比 ECDSA +等价物大 70 倍以上,公钥大 80 倍以上。 +其他 PQC 家族更甚:基于哈希的方案如 +SPHINCS+ 可产生高达 41 KB 的签名,而像 FALCON 这类尺寸优化格变体 +仍显著大于经典规模。 + +在区块链语境下,这些膨胀的规模会累积为 +系统性扩展问题。更大的签名使单笔交易膨胀,区块更快填满并需要更长验证时间,从而降低每秒交易数(TPS)。同时挤压点对点(P2P)通信,增加带宽与 +传播延迟,在工作量证明等共识机制中可能提高分叉或 +孤块风险。 +存储需求亦受影响,节点运营成本更高、参与门槛更高,尤其对 +资源有限的用户或验证者。 + + + 所有区块链未来都必须应对这些扩展挑战。例如,若不提高最大区块大小, 比特币的 + TPS 将远低于 1。 + + + + +### 协调问题 + +比特币的保守文化抵制协议变更。任何 PQC 改进 +都需在迁移期限、 +可能的代币没收与区块大小增加等有争议问题上达成共识。 +即便社区同意,每位用户 +也必须将资金迁移到量子安全的新地址。 +迁移要求所有加密资产持有者行动, +其中许多人已丢失钱包访问权限或忽视 +威胁。 + +这些问题存在于所有公链,但对比特币尤为 +困难,因其缺乏明确领导且奉行 +技术僵化哲学。 + +### 丢失币问题 + +据估计约有 2500 亿至 5000 亿美元的比特币因密钥丢失、持有人去世或 +遗忘钱包而永久无法访问。[3] 这些币无法迁移,相当于公开悬赏制造密码学相关量子计算机(CRQC)。量子攻击者将从未迁移的公钥推导私钥,并可能将数百亿美元 +的 BTC 倾泻到市场。 + +> 唯一的技术方案需要严格的期限 +> 冻结未迁移的币:这在政治上 +> 不可行。 + +若无此类期限,未迁移的币将被盗取并出售,冲击市场并摧毁 +对网络的信任。 + +### 迁移时间表问题 + +后量子签名比当前比特币签名大约 20 至 80 倍。 +若无根本性架构变更,比特币性能 +将跌至本已有限的容量的一小部分。 + +假设比特币解决政治与技术挑战, +迁移本身仍需数月或数年。每位持有人至少需 +发送一笔交易,将资金移至量子安全地址。 +许多人会先发送试探交易。臃肿的 PQC 签名压制吞吐时,网络将面临持续数月或数年的队列,而量子脆弱资金仍暴露在外。 + + + 这些叠加的挑战使向现有链添加量子安全变得极其困难。 Quantus Network + 通过从第一天起将量子安全内置于链上来规避这一问题。 + + + + +### 基础 + +Quantus Network 构建于 Substrate 之上,这是由曾参与 Ethereum 与 +Polkadot 的 Parity Technologies 开发的区块链 SDK。Substrate 高度模块化,便于替换组件以聚焦 Quantus 的独特之处。 + +Quantus 对 Substrate 的增强包括: + +- 增加后量子签名方案支持 +- 将网络 p2p 安全升级为后量子 +- 增加用户可控的交易可逆性 +- 通过将所有数据类型与域元素边界对齐,使数据库与 zk 兼容 + +### 后量子密码原语 + +Quantus Network 采用 NIST 标准化的 PQC,确保交易与网络通信在 +量子威胁下的安全。交易完整性的核心是 **ML-DSA** +(基于模格的数字签名算法,曾名 +CRYSTALS-Dilithium),一种基于格的签名方案,因其在安全性、效率与实现便利性之间的平衡而被选中。ML-DSA 利用 +Learning With Errors(LWE)与 Short Integer Solution(SIS)在 +模格上的难度等问题,对包括 Shor 算法在内的经典与量子攻击提供强韧抵抗。 + +对交易签名,Quantus 集成 **ML-DSA-87**,即最高安全级别参数集(NIST 第 5 级, +相当于经典 256 位与量子 128 位), +以防范格密码分析的可能进展。该选择侧重审慎,因格密码相对新颖,实战检验少于经典方案。 +更大参数可缓解格密码分析潜在突破的风险,较小密钥尺寸反而可能成为更弱目标。 + +#### 备选方案 + +相对 FN-DSA(Falcon)等替代方案选择 ML-DSA,因 FN-DSA 实现更复杂(例如需要 +浮点运算,不适合区块链)、规范中无确定性密钥生成,且开发时尚未最终定稿。 + +未选择基于哈希的 SLH-DSA 等选项,因其签名更大(超过 17 KB)。密码敏捷性 +(可更换签名方案)已内置于 +Substrate,未来若情况需要,添加这些替代相对容易。 + +尽管 ML-DSA-87 产生更大密钥与签名,在 Quantus 早期网络中仍可管理,此时存储尚非瓶颈,且 wormhole 地址配合 +零知识证明等优化将解决扩展问题。 + +实现技术细节见 [QIP-0006](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0006.md)。 + +### LibP2P — 量子安全的网络 + +Quantus Network 通过结合 ML-DSA 认证 +与 **ML-KEM**(基于模格的密钥封装机制, +曾名 CRYSTALS-Kyber)加密,保护点对点(P2P)节点通信。该集成将 PQC 延伸至 libp2p 栈,修改 +核心组件以实现抗量子:ML-DSA-87 签名用于对等身份,ML-KEM-768 用于传输安全 +(通过向 Noise 握手增加额外 KEM 消息以获取抗量子共享密钥)。 + +P2P 层在量子安全分析中常被忽视。 +对等认证重要,但攻击者在 P2P 层最坏情况是冒充节点并发送无效 +消息,可能导致拒绝服务。该风险已因区块链模型中节点通常不受信任且检测到攻击后可轻易换钥而缓解。同理,解密 P2P 通信对攻击者收益有限(例如追踪交易路径,可用代理或 Tor 缓解),且多数数据最终链上公开。 + +尽管如此,对 P2P 层做量子安全加固可抵御 +窃听、中间人与量子解密, +确保节点 gossip、区块传播及其他网络交互在可预见未来仍保密且完整。 + +技术细节见 [QIP-0004](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0004.md)。 + +### PQC 扩展 — wormhole 地址 + +为应对后量子密码固有的扩展挑战,Quantus Network 引入一种创新的聚合后量子签名方案 **「Wormhole Addresses」**。 +该系统利用 Plonky2 证明系统(本质为 STARK)生成的零知识证明(ZKP), +将余额验证移出链上,使链仅需验证单一紧凑证明而无需处理单笔签名。 +Wormhole Addresses 可用一条证明验证大量 +交易,主要限制来自公开输入(如 nullifier、 +存储根、输出地址与金额)。这使摊销到每笔交易的存储需求降至约每交易额外 256 字节, +远低于任何已知 PQC 签名方案。 + +该方案的量子安全来自使用抗碰撞哈希函数 +**Poseidon2** 通过 FRI(Fast +Reed-Solomon Interactive Oracle Proofs)做承诺,而非 SNARK 中常见的易受量子威胁的椭圆曲线配对。 + +此外,认证秘密隐藏在 +Poseidon2 之后。安全哈希仅被 Grover 算法二次削弱, +不会「破解」;哈希原像证明可在 ZK 场景中充当轻量后量子签名, +类似 SPHINCS+ 等基于哈希的方案。 + +#### 客户端 / 证明者流程 + +用户生成可证明不可花费的地址,通过对盐与秘密拼接后双重哈希: + +``` +H(H(salt|secret)) +``` + +该构造避免假阳性(例如将简单哈希公钥与不可花费地址混淆),因为在 Substrate +(及一般区块链)中,地址是对公钥的单一哈希,公钥由私钥经某代数运算导出, +而非安全哈希。构造安全性因此归结为寻找安全哈希的「原像的原像」。发往该地址的代币实质被销毁。 +无法花费,因接收地址无私钥对应。这些币可重新铸造 +而不膨胀总供应。 + +每笔转账创建存储对象 TransferProof, +包含如全局唯一转账计数等细节。用户钱包从最近区块头的 +存储根生成 Merkle-Patricia-Trie(MPT)存储证明至该 TransferProof 的叶子。 +计算 nullifier 以防止双花: + +``` +H(H(salt | secret | global_transfer_count)) +``` + +#### 聚合器流程 + +任意方(客户端、矿工或第三方)可通过 Plonky2 递归聚合多份 +证明,形成证明树,父证明验证子证明并聚合子公开输入: + +- nullifier 原样传递 +- 输出地址去重 +- 区块哈希证明链接后仅保留最新 +- 重复输出地址的金额相加 + +#### 链 / 验证者流程 + +网络验证聚合证明:区块哈希在链上且为近期、nullifier 唯一(防双花)、证明有效。ZK 电路约束存储证明正确性、 +nullifier 精确、地址不可花费、 +输入输出余额一致及 +区块头链接。 + +#### 为何选择 Plonky2 + +- 已审计 +- 后量子 +- 无 trusted setup +- 证明 / 验证高效 +- 证明聚合顺畅 +- Rust 原生实现 +- 兼容 Substrate 的 no-std 环境 + + + 递归证明在约 170 毫秒内完成,体积紧凑(聚合证明约 100 KB)。在理想情况下,5 MB + 区块且所有交易指向同一输出时,Wormhole Addresses 单块可打包约 153,000 + 笔交易(4.9 MB / 每笔 nullifier 32 字节):相对约 685 笔原始 ML-DSA 交易(5 MB + / 每笔 7.3 KB)约为 223 倍提升。 + + +#### 安全说明 + +潜在风险包括电路 / 验证实现缺陷导致的通胀错误, +但若重新铸造超过零发送地址余额,经济上可发现。用户可选择发布第一重哈希(不泄露秘密)证明某地址为 wormhole。验证交易无签名,故需以非金融手段缓解失败交易的拒绝服务。代币供应核算仍成立,因重铸表现为新币但通过销毁维持最大供应保证。 + +更多技术细节见 [QIP-0005](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0005.md)。 + +### 共识机制 + +Quantus Network 使用工作量证明(PoW)共识算法, +在保留比特币共识理想性质的同时, +通过将 SHA-256 替换为 **Poseidon2** 以更好兼容 ZK 证明系统。 + +重要:此变更并非出于量子安全。 +SHA-256 等密码学哈希被量子算法(尤其 Grover)削弱但未被摧毁。 +部分后量子签名方案以安全哈希为基本构件亦出于此因。 + +Poseidon2 是 Poseidon 哈希的改进。为使用 SHA-256 等传统哈希的 +计算构建 SNARK 或 STARK 通常需要约多 100 倍的 +门,而 Poseidon 完全基于域元素的代数函数而非位运算。 + +我们对 Poseidon2 与 Plonky2 使用 **Goldilocks 域**。Goldilocks 域阶 +可容纳于 64 位无符号整数,提高效率而不损害稳健性。 + + + +管理加密货币密钥存在诸多风险,其中大多数 +可以避免。 + +### 可逆交易 + +Quantus Network 提供用户可配置的可逆交易。 +发送方可设定时间窗口,在此期间可取消对外转账。这有助于遏制盗窃并在不牺牲终局性的前提下纠正错误。系统使用修改过的 Substrate「scheduler」 pallet +与时间戳。钱包为发送方显示倒计时(带取消按钮)并为接收方显示。 + +可逆交易在链上执行的前提下支持新颖安全协议并保持 +去中心化。 + +更多技术细节见 [QIP-0009](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0009.md)。 + +### 校验短语 + +Quantus Network 引入「check-phrases」,一种可读且密码学安全的区块链地址校验和。对地址哈希生成来自 BIP-39 词表的短词序列。校验短语有助于防范笔误、篡改与地址投毒攻击。50,000 次迭代的密钥派生函数提高彩虹表攻击成本。大额交易用户仍应逐字核对地址。 + +更多技术细节见 [QIP-0008](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0008.md)。 + +### 高安全性账户 + +任意账户可升级为「高安全性账户」,对所有对外转账强制可逆期。指定的 **监护人** +(硬件钱包、多签或可信第三方)可在可逆期内取消可疑交易,将资金转给监护人而非发送方或接收方。该可选功能一旦启用即永久有效,防止窃贼自行关闭。 + +监护人可链式配置:高安全性账户的监护人本身可以是带另一监护人的高安全性账户。形成可组合层级,每位监护人对所保护账户拥有更高权限。该设计给用户时间发现与应对未授权活动,而不损害合法转账的终局性。 + +更多技术细节见 [QIP-0011](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0011.md)。 + +### 密钥恢复 + +许多加密财富随持有人离世而永久丢失。 +Quantus Network 提供简单方式指定可随时提款的恢复地址,但受固定延迟约束。延迟期间,若持有人仍能访问密钥,可拒绝恢复。该功能实现链上「遗嘱」而无需法院或正式继承程序。 + +### HD-Lattice + +分层确定性(HD)钱包是行业 +标准,允许用单一助记词备份所有 +密钥,相较每笔操作手动抄写更安全便捷。将其适配 Dilithium 等格方案面临两项 +挑战: + +- HMAC-SHA512 输出无法直接构成格私钥(格上采样的多项式需满足特定性质)。 +- 非硬化密钥派生依赖椭圆曲线加法,格上不存在(公钥对任意代数运算不封闭)。 + +Quantus Network 对第一点将 HMAC 输出用作熵以确定性构建私钥, +而非直接作为密钥本身。第二点重要性较低,格密码能否适配仍是开放研究问题。 + +更多技术细节见 [QIP-0002](https://github.com/Quantus-Network/improvement-proposals/tree/main/qip-0002)。 + + + +Quantus Network 处于变化环境中,无法假设 +一次就做对。因此我们选择简单起点,并允许治理系统随新信息演进。该设计使区块链成为可适应环境的活体。尤其 Substrate 的治理流程 +可在各节点运营商最小协调下对链进行深度变更。 + +### 区块奖励 + +Quantus Network 采用模仿比特币的简单代币模型。最大供应为 **2,100 万枚**,简单启发式决定每块奖励: + +``` +block_reward = (max_supply - current_supply) / constant +``` + +该启发式在 `current_supply` 随 `block_reward` 增加时形成平滑下降的指数曲线,从而降低下一区块计算的 `block_reward`。手续费等销毁降低 `current_supply` 并计入区块奖励预算。选择常数使得在无销毁情况下约 30 年可发行 99% 的币。 + +### 投资者分配 + +Quantus Network 在投资者承担高风险资助下建成。私募投资者受 4 年归属期约束, +与团队一致。公募投资者首日即可全额流通。公募所募资金将 +与代币配对并用于流动性(DEX、CEX 与做市商)。这些投资者分配与流动性构成唯一「预挖」。其余代币须挖至存在。 + +若公募售出低于 10% 上限,流动性代币将按比例削减,其余通过区块奖励向矿工发行。 + +### 公司分配 + +为补偿团队承担无成功保证的新技术建设风险,约四年内部分区块奖励流向 +公司。这相当于公司总供应约 **15%** 的事实归属期。 + +此后,公司在区块奖励中的份额可根据代币持有人投票关闭、调整或重定向。 + +### 交易手续费 + + + +### 无分叉升级 + +Quantus Network 通过 Substrate 的 runtime 升级支持「无分叉」升级,使区块链核心逻辑(「runtime」)演进而无需扰乱网络或分裂社区的硬分叉。通过链上治理公投实现:获批提案激活 runtime 替换——在单一块内用新 WASM 代码 blob 替换旧 blob,保持状态连续与 +运营。该路径减少停机与风险, +赋能社区随实际使用迭代完善协议。 + +随社区对系统信心增强,变更 runtime 的权力将显著收窄,以限制恶意控制升级流程时的攻击面。 + +### 治理体系 + +Quantus Network 通过 Substrate 继承 Polkadot 的 OpenGov 框架。代币持有人通过 **信念投票** 参与,将资产锁定不同时长以放大投票权重。放大倍数可从 1x(不锁定)到 6x(最长锁定)。 +该设计通过将影响力与承诺绑定以鼓励长期一致。 + +提案按多条投票轨道「origins」分类。每条 origin 有定制参数,如批准阈值(例如高影响变更需绝对多数)、防垃圾最低押金、准备 / 执行期与决策时限以避免僵局。多轨道设计可并行处理从日常国库支出到关键 runtime 升级的各类公投。 + +**Technical Collective** 是由技术专家组成的精选团体, +作为专门机构提出、审查或白名单紧急技术事项, +通过专用轨道加速处理并保持社区监督。 + +Quantus 原样采用该体系,但初期采用极简配置以降低早期复杂度。最初仅启用 Technical Collective 轨道,用于协议升级或 +参数调整等高权限约束性决策。 + +日后 Quantus 可增加非约束性社区投票轨道以探测对不可强制执行议题(如功能建议或生态调查)的民意。待公司将网络移交 DAO 后,该体系可变为有约束力。分阶段方法使网络可通过未来治理投票有机演进, +而不在一开始向用户强加不必要复杂度。 + + + +截至 2026 年的当前路线图,可能变更。 + + + + + + + + + + + + + + + +
    + + + +构建 Quantus Network 存在固有风险。 + +### 实现问题 + +软件逻辑缺陷即使在设计良好的系统中也可能导致严重故障。 + +### NIST 算法选择问题 + +已选后量子标准(如 ML-DSA、ML-KEM)在标准化后可能暴露缺陷或后门。最坏情况下,此类缺陷可使攻击者通过公钥伪造签名推导私钥,构成链的灾难性失效模式。若缺陷公开,Quantus Network 可升级至新算法, +但若被低调利用可能永远无法 +发现。 + +### 量子计算时间表 + +量子进展可能远晚于预期, +推迟 PQC 需求;反之,秘密开发(例如政府)若区块链社区 +未能快速升级,可能带来突发威胁。 + +### 其他考量 + +一般采用障碍、金融 / 区块链监管不确定性以及加密生态固有的波动性。 + + + +
    + + + Shor, P. W. (1997). Polynomial-time algorithms for prime factorization and + discrete logarithms on a quantum computer. _SIAM Journal on Computing_, 26(5), + 1484–1509. https://doi.org/10.1137/S0097539795293172 + + + + Grover, L.K. (1996). A fast quantum mechanical algorithm for database search. + _Proceedings of the Twenty-Eight Annual ACM Symposium on Theory of Computing_, + 212-219. https://doi.org/10.1145/237814.237866 + + + + Chainalysis. (2024). _The Chainalysis 2024 Crypto Crime Report_. + https://www.chainalysis.com/blog/2024-crypto-crime-report-introduction/ + + + + National Institute of Standards and Technology. (2024). _FIPS 204: + Module-Lattice-Based Digital Signature Standard (ML- DSA)_. U.S. Department of + Commerce. https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf + + + + National Institute of Standards and Technology. (2024). _FIPS 203: + Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)_. U.S. + Department of Commerce. + https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf + + + + Häner, T., Jaques, S., Naehrig, M., Roetteler, M., & Soeken, M. (2020). + Improved quantum circuits for elliptic curve discrete logarithms. + _arXiv:2002.12480_. https://arxiv.org/abs/2002.12480 + + + + Gidney, C., & Ekerå, M. (2021). _How to factor 2048 bit RSA integers in 8 + hours using 20 million noisy qubits_. _arXiv:1905.09749_. + https://arxiv.org/abs/1905.09749 + + + + Aggarwal, D., et al. (2021). Assessment of Quantum Threat To Bitcoin and + Derived Cryptocurrencies. _ePrint IACR_. https://eprint.iacr.org/2021/967.pdf + + + + Roetteler, M., Naehrig, M., Svore, K. M., & Lauter, K. (2017). Quantum + resource estimates for computing elliptic curve discrete logarithms. + _arXiv:1706.06752_. https://arxiv.org/abs/1706.06752 + + + + Open Quantum Safe Project. (n.d.). ML-DSA | Open Quantum Safe. Retrieved + January 29, 2026, from + https://openquantumsafe.org/liboqs/algorithms/sig/ml-dsa.html + diff --git a/website/src/i18n/de-DE.json b/website/src/i18n/de-DE.json index add37aa..4b94b98 100644 --- a/website/src/i18n/de-DE.json +++ b/website/src/i18n/de-DE.json @@ -783,8 +783,12 @@ "last_updated": "Zuletzt aktualisiert", "changelog": "Änderungsprotokoll", "authors": "Autoren", + "published": "Veröffentlicht", + "classification": "Klassifizierung", "abstract": "Zusammenfassung", - "back_to_top": "Nach oben" + "back_to_top": "Nach oben", + "tag_line": "quantensicher, verschlüsseltes Geld", + "whitepaper": "Whitepaper" }, "common": { "loading": "Wird geladen...", diff --git a/website/src/i18n/en-US.json b/website/src/i18n/en-US.json index cb72a2b..4ab6762 100644 --- a/website/src/i18n/en-US.json +++ b/website/src/i18n/en-US.json @@ -783,8 +783,12 @@ "last_updated": "Last updated", "changelog": "Changelog", "authors": "Authors", + "published": "Published", + "classification": "Classification", "abstract": "Abstract", - "back_to_top": "Back to top" + "back_to_top": "Back to top", + "tag_line": "quantum secure, encrypted money", + "whitepaper": "Whitepaper" }, "common": { "loading": "Loading...", diff --git a/website/src/i18n/es-ES.json b/website/src/i18n/es-ES.json index e5b6f76..7f0d191 100644 --- a/website/src/i18n/es-ES.json +++ b/website/src/i18n/es-ES.json @@ -783,8 +783,12 @@ "last_updated": "Última actualización", "changelog": "Registro de cambios", "authors": "Autores", + "published": "Publicado", + "classification": "Clasificación", "abstract": "Resumen", - "back_to_top": "Volver arriba" + "back_to_top": "Volver arriba", + "tag_line": "dinero cifrado y seguro en el sentido cuántico", + "whitepaper": "Whitepaper" }, "common": { "loading": "Cargando...", diff --git a/website/src/i18n/hi-IN.json b/website/src/i18n/hi-IN.json index 65150c5..d3e9624 100644 --- a/website/src/i18n/hi-IN.json +++ b/website/src/i18n/hi-IN.json @@ -786,8 +786,12 @@ "last_updated": "अंतिम अपडेट", "changelog": "परिवर्तन लॉग", "authors": "लेखक", + "published": "प्रकाशित", + "classification": "वर्गीकरण", "abstract": "सारांश", - "back_to_top": "शीर्ष पर वापस जाएँ" + "back_to_top": "शीर्ष पर वापस जाएँ", + "tag_line": "क्वांटम-सुरक्षित, एन्क्रिप्टेड धन", + "whitepaper": "व्हाइटपेपर" }, "common": { "loading": "लोड हो रहा है...", diff --git a/website/src/i18n/id-ID.json b/website/src/i18n/id-ID.json index 8598d90..72c50a8 100644 --- a/website/src/i18n/id-ID.json +++ b/website/src/i18n/id-ID.json @@ -783,8 +783,12 @@ "last_updated": "Terakhir diperbarui", "changelog": "Catatan Perubahan", "authors": "Penulis", + "published": "Diterbitkan", + "classification": "Klasifikasi", "abstract": "Abstrak", - "back_to_top": "Kembali ke atas" + "back_to_top": "Kembali ke atas", + "tag_line": "uang aman kuantum, terenkripsi", + "whitepaper": "Whitepaper" }, "common": { "loading": "Memuat...", diff --git a/website/src/i18n/ja-JP.json b/website/src/i18n/ja-JP.json index 801f730..d39df8c 100644 --- a/website/src/i18n/ja-JP.json +++ b/website/src/i18n/ja-JP.json @@ -775,8 +775,12 @@ "last_updated": "最終更新", "changelog": "変更履歴", "authors": "著者", + "published": "公開", + "classification": "区分", "abstract": "概要", - "back_to_top": "トップに戻る" + "back_to_top": "トップに戻る", + "tag_line": "量子セキュアで暗号化されたマネー", + "whitepaper": "ホワイトペーパー" }, "common": { "loading": "読み込み中...", diff --git a/website/src/i18n/ko-KR.json b/website/src/i18n/ko-KR.json index 8ce0b08..bfd75b5 100644 --- a/website/src/i18n/ko-KR.json +++ b/website/src/i18n/ko-KR.json @@ -775,8 +775,12 @@ "last_updated": "마지막 업데이트", "changelog": "변경 이력", "authors": "저자", + "published": "게시", + "classification": "분류", "abstract": "요약", - "back_to_top": "맨 위로" + "back_to_top": "맨 위로", + "tag_line": "양자 보안, 암호화된 화폐", + "whitepaper": "백서" }, "common": { "loading": "로딩 중...", diff --git a/website/src/i18n/ru-RU.json b/website/src/i18n/ru-RU.json index 54b1dfb..d1c0db6 100644 --- a/website/src/i18n/ru-RU.json +++ b/website/src/i18n/ru-RU.json @@ -783,8 +783,12 @@ "last_updated": "Последнее обновление", "changelog": "История изменений", "authors": "Авторы", + "published": "Опубликовано", + "classification": "Классификация", "abstract": "Аннотация", - "back_to_top": "Наверх" + "back_to_top": "Наверх", + "tag_line": "квантовая безопасность, зашифрованные деньги", + "whitepaper": "Whitepaper" }, "common": { "loading": "Загрузка...", diff --git a/website/src/i18n/zh-CN.json b/website/src/i18n/zh-CN.json index 4273dc4..8ce38be 100644 --- a/website/src/i18n/zh-CN.json +++ b/website/src/i18n/zh-CN.json @@ -772,8 +772,12 @@ "last_updated": "最后更新", "changelog": "更新日志", "authors": "作者", + "published": "发布", + "classification": "分类", "abstract": "摘要", - "back_to_top": "返回顶部" + "back_to_top": "返回顶部", + "tag_line": "量子安全,加密货币", + "whitepaper": "白皮书" }, "common": { "loading": "加载中...", diff --git a/website/src/pages/[lang]/whitepaper.astro b/website/src/pages/[lang]/whitepaper.astro index 404b82b..c01bd60 100644 --- a/website/src/pages/[lang]/whitepaper.astro +++ b/website/src/pages/[lang]/whitepaper.astro @@ -17,7 +17,9 @@ import { getWhitepapersForLocale, getAllVersions, getWhitepaperPdfPath, + resolveWhitepaperTocHeadings, } from "@/utils/whitepaper"; +import WhitepaperPrintCover from "@/components/features/whitepaper/WhitepaperPrintCover.astro"; export async function getStaticPaths() { return SUPPORTED_LOCALES.map((lang) => ({ params: { lang } })); @@ -35,7 +37,8 @@ const latestVersion = versions[versions.length - 1]?.version ?? entry.data.version; const pdfHref = getWhitepaperPdfPath(locale, entry.data.version); -const { Content, headings } = await render(entry); +const { Content, headings: renderHeadings } = await render(entry); +const headings = resolveWhitepaperTocHeadings(entry, renderHeadings); const metadata = createMetadata({ title: t("whitepaper.meta.title"), @@ -47,6 +50,8 @@ const jsonLd = JsonLdGraph({ "@context": "https://schema.org", "@graph": [getWhitepaperJsonLd(locale, entry.data.version)], }); + +const styleVersion = entry.data.version === "0.3.1" ? "v1" : "v2"; --- @@ -54,6 +59,18 @@ const jsonLd = JsonLdGraph({ id="whitepaper-section" class:list={["lg:max-w-content mx-auto px-[30px] py-10 lg:py-20 2xl:px-0"]} > + { + entry.data.pdfCover && ( + + ) + } +
    - +
    diff --git a/website/src/pages/[lang]/whitepaper/[version].astro b/website/src/pages/[lang]/whitepaper/[version].astro index 58dae87..0778ffe 100644 --- a/website/src/pages/[lang]/whitepaper/[version].astro +++ b/website/src/pages/[lang]/whitepaper/[version].astro @@ -11,6 +11,7 @@ import { JsonLdGraph } from "@/utils/build-json-ld"; import { getWhitepaperJsonLd } from "@/constants/default-jsonld"; import { createMetadata } from "@/utils/create-metadata"; import WhitepaperHeader from "@/components/features/whitepaper/WhitepaperHeader.astro"; +import WhitepaperPrintCover from "@/components/features/whitepaper/WhitepaperPrintCover.astro"; import TableOfContents from "@/components/features/whitepaper/TableOfContents.astro"; import WhitepaperContent from "@/components/features/whitepaper/WhitepaperContent.astro"; import { @@ -18,6 +19,7 @@ import { getWhitepapersForLocale, getAllVersions, getWhitepaperPdfPath, + resolveWhitepaperTocHeadings, } from "@/utils/whitepaper"; export async function getStaticPaths() { @@ -57,7 +59,8 @@ const latestVersion = versions[versions.length - 1]?.version ?? entry.data.version; const pdfHref = getWhitepaperPdfPath(locale as Locale, entry.data.version); -const { Content, headings } = await render(entry); +const { Content, headings: renderHeadings } = await render(entry); +const headings = resolveWhitepaperTocHeadings(entry, renderHeadings); const metadata = createMetadata({ title: `${t("whitepaper.meta.title")} - v${entry.data.version}`, @@ -69,6 +72,8 @@ const jsonLd = JsonLdGraph({ "@context": "https://schema.org", "@graph": [getWhitepaperJsonLd(locale, entry.data.version)], }); + +const styleVersion = entry.data.version === "0.3.1" ? "v1" : "v2"; --- @@ -76,6 +81,18 @@ const jsonLd = JsonLdGraph({ id="whitepaper-section" class:list={["lg:max-w-content mx-auto px-[30px] py-10 lg:py-20 2xl:px-0"]} > + { + entry.data.pdfCover && ( + + ) + } +
    - +
    diff --git a/website/src/pages/whitepaper.astro b/website/src/pages/whitepaper.astro index e1992bd..c5d1bd1 100644 --- a/website/src/pages/whitepaper.astro +++ b/website/src/pages/whitepaper.astro @@ -13,7 +13,9 @@ import { getWhitepapersForLocale, getAllVersions, getWhitepaperPdfPath, + resolveWhitepaperTocHeadings, } from "@/utils/whitepaper"; +import WhitepaperPrintCover from "@/components/features/whitepaper/WhitepaperPrintCover.astro"; const locale = getLocaleFromUrl(Astro.url.pathname); const t = await createTranslator(locale); @@ -27,7 +29,8 @@ const latestVersion = versions[versions.length - 1]?.version ?? entry.data.version; const pdfHref = getWhitepaperPdfPath(locale, entry.data.version); -const { Content, headings } = await render(entry); +const { Content, headings: renderHeadings } = await render(entry); +const headings = resolveWhitepaperTocHeadings(entry, renderHeadings); const metadata = createMetadata({ title: t("whitepaper.meta.title"), @@ -39,6 +42,8 @@ const jsonLd = JsonLdGraph({ "@context": "https://schema.org", "@graph": [getWhitepaperJsonLd(locale, entry.data.version)], }); + +const styleVersion = entry.data.version === "0.3.1" ? "v1" : "v2"; --- @@ -46,6 +51,18 @@ const jsonLd = JsonLdGraph({ id="whitepaper-section" class:list={["lg:max-w-content mx-auto px-[30px] py-10 lg:py-20 2xl:px-0"]} > + { + entry.data.pdfCover && ( + + ) + } +
    - +
    diff --git a/website/src/pages/whitepaper/[version].astro b/website/src/pages/whitepaper/[version].astro index 8afa4f9..5a6c0cd 100644 --- a/website/src/pages/whitepaper/[version].astro +++ b/website/src/pages/whitepaper/[version].astro @@ -6,6 +6,7 @@ import { JsonLdGraph } from "@/utils/build-json-ld"; import { getWhitepaperJsonLd } from "@/constants/default-jsonld"; import { createMetadata } from "@/utils/create-metadata"; import WhitepaperHeader from "@/components/features/whitepaper/WhitepaperHeader.astro"; +import WhitepaperPrintCover from "@/components/features/whitepaper/WhitepaperPrintCover.astro"; import TableOfContents from "@/components/features/whitepaper/TableOfContents.astro"; import WhitepaperContent from "@/components/features/whitepaper/WhitepaperContent.astro"; import { @@ -13,6 +14,7 @@ import { getWhitepapersForLocale, getAllVersions, getWhitepaperPdfPath, + resolveWhitepaperTocHeadings, } from "@/utils/whitepaper"; export async function getStaticPaths() { @@ -40,7 +42,8 @@ const latestVersion = versions[versions.length - 1]?.version ?? entry.data.version; const pdfHref = getWhitepaperPdfPath(locale, entry.data.version); -const { Content, headings } = await render(entry); +const { Content, headings: renderHeadings } = await render(entry); +const headings = resolveWhitepaperTocHeadings(entry, renderHeadings); const metadata = createMetadata({ title: `${t("whitepaper.meta.title")} - v${entry.data.version}`, @@ -52,6 +55,8 @@ const jsonLd = JsonLdGraph({ "@context": "https://schema.org", "@graph": [getWhitepaperJsonLd(locale, entry.data.version)], }); + +const styleVersion = entry.data.version === "0.3.1" ? "v1" : "v2"; --- @@ -59,6 +64,18 @@ const jsonLd = JsonLdGraph({ id="whitepaper-section" class:list={["lg:max-w-content mx-auto px-[30px] py-10 lg:py-20 2xl:px-0"]} > + { + entry.data.pdfCover && ( + + ) + } +
    - +
    diff --git a/website/src/styles/colors.css b/website/src/styles/colors.css index a2519a8..1284931 100644 --- a/website/src/styles/colors.css +++ b/website/src/styles/colors.css @@ -100,6 +100,18 @@ /* Roadmap Colors */ --color-marker-line: #f4f6f9; + + /* Whitepapers Colors */ + --color-whitepaper-primary: #ff6b35; + --color-whitepaper-body-light: #111111; + --color-whitepaper-body: #1a1a1a; + --color-whitepaper-tagline: #0e0e0e66; + --color-whitepaper-divider: #e8e8e8; + --color-whitepaper-section-title-alt: #888; + --color-whitepaper-callout-background: #f6f6f4; + --color-whitepaper-pre-background: #f6f6f4; + --color-whitepaper-cover-label: #0e0e0e; + --color-whitepaper-cover-tagline: #0e0e0e66; } @utility text-gradient-giant { diff --git a/website/src/styles/fonts.css b/website/src/styles/fonts.css index 677720c..7f874cf 100644 --- a/website/src/styles/fonts.css +++ b/website/src/styles/fonts.css @@ -1,6 +1,8 @@ @theme { --font-primary: "Prompt", "sans-serif"; --font-secondary: "Inter", "sans-serif"; + --font-whitepaper-primary: "IBM Plex Sans", "sans-serif"; + --font-whitepaper-secondary: "IBM Plex Mono", "monospace"; } /* Note: font-display: swap is handled by @fontsource packages. @@ -286,3 +288,174 @@ letter-spacing: 1.8px; text-transform: uppercase; } + +/* Whitepapers Fonts */ +@utility font-whitepaper-cover-version { + font-family: var(--font-whitepaper-secondary); + font-size: 8px; + font-weight: 400; + line-height: normal; + letter-spacing: 0.08px; + text-transform: uppercase; +} +@utility font-whitepaper-cover-title { + font-family: var(--font-primary); + font-size: 80px; + font-weight: 700; + line-height: normal; + letter-spacing: 0.8px; + text-transform: lowercase; +} +@utility font-whitepaper-cover-tagline { + font-family: var(--font-whitepaper-secondary); + font-size: 12px; + font-weight: 400; + line-height: 135%; /* 16.2px */ + letter-spacing: 0.12px; + text-transform: lowercase; +} +@utility font-whitepaper-cover-credit-label { + font-family: var(--font-whitepaper-secondary); + font-size: 8px; + font-weight: 400; + line-height: normal; + letter-spacing: 0.08px; + text-transform: uppercase; +} +@utility font-whitepaper-cover-credit-content { + font-family: var(--font-whitepaper-secondary); + font-size: 10px; + font-weight: 500; + line-height: 135%; /* 13.5px */ + letter-spacing: 0.1px; + text-transform: lowercase; +} +@utility font-whitepaper-chapter-number { + font-family: var(--font-primary); + font-size: 85.3px; + font-weight: 700; + line-height: 85.33px; + letter-spacing: -4px; +} +@utility font-whitepaper-chapter-title { + font-family: var(--font-primary); + font-size: 37.3px; + font-weight: 700; + line-height: 41px; /* 109.92% */ + letter-spacing: -0.667px; + text-transform: lowercase; +} +@utility font-whitepaper-section-paragraph { + font-family: var(--font-whitepaper-primary); + font-size: 21.3px; + font-weight: 400; + line-height: 37.97px; + letter-spacing: 0%; +} +@utility font-whitepaper-blockquote { + font-family: var(--font-whitepaper-secondary); + font-size: 21.3px; + font-weight: 300; + line-height: 32px; + letter-spacing: -0.427px; +} +@utility font-whitepaper-section-title { + font-family: var(--font-primary); + font-size: 21.3px; + font-weight: 700; + line-height: 35.2px; + letter-spacing: 0.427px; + text-transform: lowercase; +} +@utility font-whitepaper-sub-section-title { + font-family: var(--font-whitepaper-secondary); + font-size: 21.3px; + font-weight: 500; + line-height: 35.2px; /* 165.258% */ + letter-spacing: 1.28px; + text-transform: lowercase; +} +@utility font-whitepaper-section-title-alt { + font-family: var(--font-whitepaper-secondary); + font-size: 21.3px; + font-weight: 400; + line-height: 35.2px; /* 165.258% */ + letter-spacing: 4.267px; + text-transform: uppercase; +} +@utility font-whitepaper-ordered-list-bullet { + font-family: var(--font-whitepaper-secondary); + font-size: 21.3px; + font-weight: 700; + line-height: 35.2px; /* 165.258% */ +} +@utility font-whitepaper-ordered-list-item { + font-family: var(--font-whitepaper-secondary); + font-size: 21.3px; + font-weight: 400; + line-height: 35.2px; /* 165.258% */ + letter-spacing: -0.213px; + text-transform: lowercase; +} +@utility font-whitepaper-timeline-title { + font-family: var(--font-whitepaper-secondary); + font-size: 21.3px; + font-weight: 700; + line-height: 35.2px; /* 165.258% */ + text-transform: lowercase; +} +@utility font-whitepaper-timeline-date { + font-family: var(--font-whitepaper-secondary); + font-size: 21.3px; + font-weight: 400; + line-height: 35.2px; + letter-spacing: 0.853px; +} +@utility font-whitepaper-reference-label { + font-family: var(--font-whitepaper-secondary); + font-size: 21.3px; + font-weight: 700; + line-height: 35.2px; /* 165.258% */ +} +@utility font-whitepaper-reference-marker { + font-family: var(--font-whitepaper-secondary); + font-size: 21.3px; + font-weight: 400; + line-height: 37.97px; + letter-spacing: 0.853px; +} +@utility font-whitepaper-table-header { + font-family: var(--font-whitepaper-secondary); + font-size: 21.3px; + font-weight: 700; + line-height: normal; + letter-spacing: 2.56px; + text-transform: uppercase; +} +@utility font-whitepaper-table-cell { + font-family: var(--font-whitepaper-secondary); + font-size: 21.3px; + font-weight: 700; + line-height: 30.93px; /* 145.211% */ +} +@utility font-whitepaper-callout-title { + font-family: var(--font-whitepaper-secondary); + font-size: 21.3px; + font-weight: 700; + line-height: 35.2px; /* 165.258% */ + letter-spacing: 3.84px; + text-transform: uppercase; +} +@utility font-whitepaper-callout-body { + font-family: var(--font-whitepaper-secondary); + font-size: 21.3px; + font-weight: 400; + line-height: 35.2px; /* 165.258% */ +} +@utility font-whitepaper-code { + font-family: var(--font-whitepaper-secondary); + font-size: 21.3px; + font-style: normal; + font-weight: 400; + line-height: 34.13px; /* 160.235% */ +} diff --git a/website/src/styles/global.css b/website/src/styles/global.css index 55166a7..b5d7d35 100644 --- a/website/src/styles/global.css +++ b/website/src/styles/global.css @@ -45,9 +45,6 @@ html, body { background: white !important; - color: #1a1a1a !important; - font-size: 11pt; - line-height: 1.6; } body { @@ -68,7 +65,6 @@ h4, h5, h6 { - color: #111 !important; page-break-after: avoid; } @@ -80,13 +76,6 @@ page-break-before: avoid; } - p, - li, - span, - div { - color: inherit; - } - table { page-break-inside: avoid; } @@ -109,7 +98,6 @@ a[href]::after { content: " (" attr(href) ")"; font-size: 0.8em; - color: #666; } a[href^="#"]::after, @@ -120,39 +108,4 @@ .prose a[href]::after { content: ""; } - - .prose { - --tw-prose-body: #333; - --tw-prose-headings: #111; - --tw-prose-lead: #555; - --tw-prose-links: #1d4ed8; - --tw-prose-bold: #111; - --tw-prose-counters: #555; - --tw-prose-bullets: #555; - --tw-prose-hr: #d0d7de; - --tw-prose-quotes: #555; - --tw-prose-quote-borders: #d0d7de; - --tw-prose-captions: #666; - --tw-prose-code: #c7254e; - --tw-prose-pre-code: #333; - --tw-prose-pre-bg: #f6f8fa; - --tw-prose-th-borders: #d0d7de; - --tw-prose-td-borders: #e1e4e8; - --tw-prose-invert-body: #333; - --tw-prose-invert-headings: #111; - --tw-prose-invert-lead: #555; - --tw-prose-invert-links: #1d4ed8; - --tw-prose-invert-bold: #111; - --tw-prose-invert-counters: #555; - --tw-prose-invert-bullets: #555; - --tw-prose-invert-hr: #d0d7de; - --tw-prose-invert-quotes: #555; - --tw-prose-invert-quote-borders: #d0d7de; - --tw-prose-invert-captions: #666; - --tw-prose-invert-code: #c7254e; - --tw-prose-invert-pre-code: #333; - --tw-prose-invert-pre-bg: #f6f8fa; - --tw-prose-invert-th-borders: #d0d7de; - --tw-prose-invert-td-borders: #e1e4e8; - } } diff --git a/website/src/utils/whitepaper.ts b/website/src/utils/whitepaper.ts index 2c02251..1e47371 100644 --- a/website/src/utils/whitepaper.ts +++ b/website/src/utils/whitepaper.ts @@ -3,6 +3,58 @@ import type { Locale } from "./i18n"; export type WhitepaperEntry = CollectionEntry<"whitepaper">; +export type WhitepaperTocHeading = { + depth: number; + slug: string; + text: string; +}; + +/** + * Astro's `render().headings` only includes markdown headings (`##` / `###`), not JSX `

    ` or + * components that render `

    `. Optional `entry.data.toc` inserts those entries next to a nearby + * markdown heading slug (`insertBefore` / `insertAfter`) so the table of contents matches the page. + */ +export function resolveWhitepaperTocHeadings( + entry: WhitepaperEntry, + renderHeadings: WhitepaperTocHeading[], +): WhitepaperTocHeading[] { + const toc = entry.data.toc; + if (!toc) return renderHeadings; + + const insertBefore = toc.insertBefore ?? {}; + const insertAfter = toc.insertAfter ?? {}; + const flat = renderHeadings.filter((h) => h.depth >= 2 && h.depth <= 3); + const out: WhitepaperTocHeading[] = []; + const beforeDone = new Set(); + + for (const h of flat) { + const pending = insertBefore[h.slug]; + if (pending?.length && !beforeDone.has(h.slug)) { + beforeDone.add(h.slug); + for (const add of pending) { + out.push({ + depth: add.depth ?? 2, + slug: add.slug, + text: add.text, + }); + } + } + out.push(h); + const afterAdds = insertAfter[h.slug]; + if (afterAdds?.length) { + for (const add of afterAdds) { + out.push({ + depth: add.depth ?? 2, + slug: add.slug, + text: add.text, + }); + } + } + } + + return out; +} + function compareVersions(a: string, b: string): number { const pa = a.split(".").map(Number); const pb = b.split(".").map(Number);