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

deploy: 73c98535fc

Browse Source
This commit is contained in:
bkchr
2024-12-13 01:12:54 +00:00
parent 7b58e0fb70
commit 965d961fe9
4 changed files with 92 additions and 74 deletions
Download Patch File Download Diff File Expand all files Collapse all files
proposed/0125-xcm-asset-metadata.html
+20 -11
View File
@@ -198,7 +198,6 @@
</ul>
</li>
<li><a href="#prior-art-and-references">Prior Art and References</a></li>
<li><a href="#unresolved-questions">Unresolved Questions</a></li>
<li><a href="#future-directions-and-related-material">Future Directions and Related Material</a></li>
</ul>
</li>
@@ -243,15 +242,26 @@ However, to communicate metadata between consensus entities via XCM, we need a g
<ol>
<li>
<p>Using key-value pairs as XCM Asset Metadata since it is a general concept useful for both structured and unstructured data. Both key and value can be raw bytes with interpretation up to the communicating entities.</p>
<p>The XCM Asset Metadata should be represented as a map SCALE-encoded equivalent to the <code>BTreeMap</code>.</p>
<p>Let's call the type of the XCM Asset Metadata map <code>MetadataMap</code>.</p>
<p>The XCM Asset Metadata should be represented as a map SCALE-encoded equivalent to the <code>BTreeMap&lt;Vec&lt;u8&gt;, Vec&lt;u8&gt;&gt;</code>.</p>
<p>As such, the XCM Asset Metadata types are defined as follows:</p>
<pre><pre class="playground"><code class="language-rust"><span class="boring">#![allow(unused)]
</span><span class="boring">fn main() {
</span>type MetadataKey = Vec&lt;u8&gt;;
type MetadataValue = Vec&lt;u8&gt;;
type MetadataMap = BTreeMap&lt;MetadataKey, MetadataValue&gt;;
<span class="boring">}</span></code></pre></pre>
</li>
<li>
<p>Communicating only the demanded part of the metadata, not the whole metadata.</p>
<ul>
<li>
<p>A consensus entity should be able to query the values of interested keys to read the metadata.
To specify the keys to read, we need a set-like type. Let's call that type <code>MetadataKeys</code> and make its instance a SCALE-encoded equivalent to the <code>BTreeSet</code>.</p>
We need a set-like type to specify the keys to read, a SCALE-encoded equivalent to the <code>BTreeSet&lt;Vec&lt;u8&gt;&gt;</code>.
Let's define that type as follows:</p>
<pre><pre class="playground"><code class="language-rust"><span class="boring">#![allow(unused)]
</span><span class="boring">fn main() {
</span>type MetadataKeySet = BTreeSet&lt;MetadataKey&gt;;
<span class="boring">}</span></code></pre></pre>
</li>
<li>
<p>A consensus entity should be able to write the values for specified keys.</p>
@@ -262,6 +272,7 @@ To specify the keys to read, we need a set-like type. Let's call that type <code
<p>New XCM instructions to communicate the metadata.</p>
</li>
</ol>
<p>Note: the maximum lengths of <code>MetadataKey</code>, <code>MetadataValue</code>, <code>MetadataMap</code>, and <code>MetadataKeySet</code> are implementation-defined.</p>
<h3 id="new-instructions"><a class="header" href="#new-instructions">New instructions</a></h3>
<h4 id="reportmetadata"><a class="header" href="#reportmetadata"><code>ReportMetadata</code></a></h4>
<p>The <code>ReportMetadata</code> is a new instruction to query metadata information.
@@ -301,11 +312,11 @@ ReportMetadata {
<pre><pre class="playground"><code class="language-rust"><span class="boring">#![allow(unused)]
</span><span class="boring">fn main() {
</span>enum MetadataQueryKind {
/// Query metadata key list.
KeyList,
/// Query metadata key set.
KeySet,
/// Query values of the specified keys.
Values(MetadataKeys),
Values(MetadataKeySet),
}
<span class="boring">}</span></code></pre></pre>
<p>The <code>ReportMetadata</code> works in conjunction with the existing <code>QueryResponse</code> instruction. The <code>Response</code> type should be modified accordingly: we need to add a new <code>AssetMetadata</code> variant to it.</p>
@@ -332,8 +343,8 @@ pub enum Response {
pub enum MetadataResponseData {
/// The metadata key list to be reported
/// in response to the `KeyList` metadata query kind.
KeyList(MetadataKeys),
/// in response to the `KeySet` metadata query kind.
KeySet(MetadataKeySet),
/// The values of the keys that were specified in the
/// `Values` variant of the metadata query kind.
@@ -383,8 +394,6 @@ This RFC proposes to use the <code>Undefined</code> variant of a collection iden
<p>This RFC proposes new functionality, so there are no compatibility issues.</p>
<h2 id="prior-art-and-references"><a class="header" href="#prior-art-and-references">Prior Art and References</a></h2>
<p><a href="https://github.com/polkadot-fellows/xcm-format/pull/50">RFC: XCM Asset Metadata</a></p>
<h2 id="unresolved-questions"><a class="header" href="#unresolved-questions">Unresolved Questions</a></h2>
<p>Should the <code>MetadataMap</code> and <code>MetadataKeys</code> be bounded, or is it enough to rely on the fact that every XCM message is itself bounded?</p>
<h2 id="future-directions-and-related-material"><a class="header" href="#future-directions-and-related-material">Future Directions and Related Material</a></h2>
<p>The original RFC draft contained additional metadata instructions. Though they could be useful, they're clearly outside the basic logic. So, this RFC version omits them to make the metadata discussion more focused on the core things. Nonetheless, there is hope that metadata approval instructions might be useful in the future, so they are mentioned here.</p>
<p>You can read about the details in the <a href="https://github.com/UniqueNetwork/xcm-format/blob/e4c989599fee3e37467ff2b4bb4e6c977c238ad3/proposals/0050-asset-metadata.md">original draft</a>.</p>