pezkuwichain/pezkuwi-fellows
1
0
Fork 0
mirror of https://github.com/pezkuwichain/pezkuwi-fellows.git synced 2026-05-30 15:01:01 +00:00
Code Issues Packages Projects Releases Wiki Activity

deploy: 73c98535fc

Browse Source
This commit is contained in:
bkchr
2025-01-08 01:05:50 +00:00
parent a169f14fa2
commit 38f873a3a2
4 changed files with 4 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
new/0135-compressed-blob-prefixes.html
+1 -1
View File
@@ -215,7 +215,7 @@
<h2 id="summary"><a class="header" href="#summary">Summary</a></h2> <h2 id="summary"><a class="header" href="#summary">Summary</a></h2>
<p>This RFC proposes a change that makes it possible to identify types of compressed blobs stored on-chain, as well as used off-chain, without the need for decompression.</p> <p>This RFC proposes a change that makes it possible to identify types of compressed blobs stored on-chain, as well as used off-chain, without the need for decompression.</p>
<h2 id="motivation"><a class="header" href="#motivation">Motivation</a></h2> <h2 id="motivation"><a class="header" href="#motivation">Motivation</a></h2>
<p>Currently, a compressed blob does not give any idea of what's inside because the only thing that can be inside, according to the spec, is Wasm. In reality, other blob types are already being used, and more are to come. Blob decompression is a blocking operation, and routing the blob to a proper worker should not involve its decompression for the sake of efficiency. Thus, it is necessary to introduce a mechanism allowing to identify the blob type without decompressing it.</p> <p>Currently, a compressed blob does not give any idea of what's inside because the only thing that can be inside, according to the spec, is Wasm. In reality, other blob types are already being used, and more are to come. Apart from being error-prone by itself, the current approach does not allow to properly route the blob through the execution paths before its decompression, which will result in suboptimal implementations when more blob types are used. Thus, it is necessary to introduce a mechanism allowing to identify the blob type without decompressing it.</p>
<p>This proposal is intended to:</p> <p>This proposal is intended to:</p>
<ol> <ol>
<li>Fill up gaps in the Polkadot spec, increasing its preciseness and putting it in line with mechanisms already being used in practice but not yet standardized;</li> <li>Fill up gaps in the Polkadot spec, increasing its preciseness and putting it in line with mechanisms already being used in practice but not yet standardized;</li>
print.html
+1 -1
View File
@@ -221,7 +221,7 @@ detailing proposed changes to the technical implementation of the Polkadot netwo
<h2 id="summary"><a class="header" href="#summary">Summary</a></h2> <h2 id="summary"><a class="header" href="#summary">Summary</a></h2>
<p>This RFC proposes a change that makes it possible to identify types of compressed blobs stored on-chain, as well as used off-chain, without the need for decompression.</p> <p>This RFC proposes a change that makes it possible to identify types of compressed blobs stored on-chain, as well as used off-chain, without the need for decompression.</p>
<h2 id="motivation"><a class="header" href="#motivation">Motivation</a></h2> <h2 id="motivation"><a class="header" href="#motivation">Motivation</a></h2>
<p>Currently, a compressed blob does not give any idea of what's inside because the only thing that can be inside, according to the spec, is Wasm. In reality, other blob types are already being used, and more are to come. Blob decompression is a blocking operation, and routing the blob to a proper worker should not involve its decompression for the sake of efficiency. Thus, it is necessary to introduce a mechanism allowing to identify the blob type without decompressing it.</p> <p>Currently, a compressed blob does not give any idea of what's inside because the only thing that can be inside, according to the spec, is Wasm. In reality, other blob types are already being used, and more are to come. Apart from being error-prone by itself, the current approach does not allow to properly route the blob through the execution paths before its decompression, which will result in suboptimal implementations when more blob types are used. Thus, it is necessary to introduce a mechanism allowing to identify the blob type without decompressing it.</p>
<p>This proposal is intended to:</p> <p>This proposal is intended to:</p>
<ol> <ol>
<li>Fill up gaps in the Polkadot spec, increasing its preciseness and putting it in line with mechanisms already being used in practice but not yet standardized;</li> <li>Fill up gaps in the Polkadot spec, increasing its preciseness and putting it in line with mechanisms already being used in practice but not yet standardized;</li>
searchindex.js
+1 -1
View File
File diff suppressed because one or more lines are too long
searchindex.json
+1 -1
View File
File diff suppressed because one or more lines are too long