From 3a71ff451e21e9ea4f1468c1b0bc68b4d230f913 Mon Sep 17 00:00:00 2001 From: bkchr Date: Mon, 15 Jul 2024 00:58:59 +0000 Subject: [PATCH] deploy: 7410f5fc806ece2c3f323a5bf4b4e2a76418cdcc --- ...2-offchain-parachain-runtime-upgrades.html | 41 +++++++++++++++++-- print.html | 41 +++++++++++++++++-- searchindex.js | 2 +- searchindex.json | 2 +- 4 files changed, 78 insertions(+), 8 deletions(-) diff --git a/new/0102-offchain-parachain-runtime-upgrades.html b/new/0102-offchain-parachain-runtime-upgrades.html index 6391346..e904b8d 100644 --- a/new/0102-offchain-parachain-runtime-upgrades.html +++ b/new/0102-offchain-parachain-runtime-upgrades.html @@ -265,7 +265,8 @@ blocks.

We discussed introducing a separate signalling before submitting the actual runtime, but I think we should just go one step further and make upgrades fully -off-chain.

+off-chain. Which also helps bringing down deposit costs in a secure way, as we +are also actually reducing costs for the network.

Introduce a new UMP message type RequestCodeUpgrade

As part of elastic scaling we are already planning to increase flexibility of UMP messages, we can now use this to our advantage and introduce another UMP message:

@@ -291,7 +292,9 @@ validators, with the following request/response:

blob_hash: Hash, } -struct BlobResponse(Vec<u8>) +struct BlobResponse { + blob: Vec<u8> +} }

This protocol will be used by backers to request the PVF from collators in the following conditions:

@@ -448,8 +451,17 @@ namely:

  • Good news, at least after the first upgrade, no code will be stored on chain any more, this means that we also have to redefine the storage deposit now. We no longer charge for chain storage, but validator disk storage -> Should -be cheaper.
    • +be cheaper. Solution to this: Not only store the hash on chain, but also the +size of the data. Then define a price per byte and charge that, but: + + +

    TODO: Fully resolve these questions and incorporate in RFC text.

    Further Hardening

    By no longer having code upgrade go through the relay chain, occupying a full relay @@ -472,6 +484,29 @@ question in a more generic way and thus could indeed open this storage facility for other purposes as well. E.g. smart contracts, so the PoV would only need to reference contracts by hash and the actual PoV is stored on validators and collators and thus no longer needs to be part of the PoV.

    +

    A possible avenue would be to change the response to:

    +
    #![allow(unused)]
+fn main() {
+enum BlobResponse {
+  Blob(Vec<u8>),
+  Blobs(MerkleTree),
+}
+}
    +

    With this the hash specified in the request can also be a merkle root and the +responder will respond with the entire merkle tree (only hashes, no payload). +Then the requester can traverse the leaf hashes and use the same request +response protocol to request any locally missing blobs in that tree.

    +

    One leaf would for example be the PVF others could be smart contracts. With a +properly specified format (e.g. which leaf is the PVF?), what we got here is +that a parachain can not only update its PVF, but additional data, +incrementally. E.g. adding another smart contract, does not require resubmitting +the entire PVF to validators, only the root hash on the relay chain gets +updated, then validators fetch the merkle tree and only fetch any missing +leaves. That additional data could be made available to the PVF via a to be +added host function. The nice thing about this approach is, that while we can +upgrade incrementally, lifetime is still tied to the PVF and we get all the same +guarantees. Assuming the validators store blobs by hash, we even get disk +sharing if multiple parachains use the same data (e.g. same smart contracts).

    diff --git a/print.html b/print.html index 1cc5633..ef265ca 100644 --- a/print.html +++ b/print.html @@ -619,7 +619,8 @@ blocks.

    We discussed introducing a separate signalling before submitting the actual runtime, but I think we should just go one step further and make upgrades fully -off-chain.

    +off-chain. Which also helps bringing down deposit costs in a secure way, as we +are also actually reducing costs for the network.

    Introduce a new UMP message type RequestCodeUpgrade

    As part of elastic scaling we are already planning to increase flexibility of UMP messages, we can now use this to our advantage and introduce another UMP message:

    @@ -645,7 +646,9 @@ validators, with the following request/response:

    blob_hash: Hash, } -struct BlobResponse(Vec<u8>) +struct BlobResponse { + blob: Vec<u8> +} }

    This protocol will be used by backers to request the PVF from collators in the following conditions:

    @@ -802,8 +805,17 @@ namely:

  • Good news, at least after the first upgrade, no code will be stored on chain any more, this means that we also have to redefine the storage deposit now. We no longer charge for chain storage, but validator disk storage -> Should -be cheaper.
    • +be cheaper. Solution to this: Not only store the hash on chain, but also the +size of the data. Then define a price per byte and charge that, but: + + +

    TODO: Fully resolve these questions and incorporate in RFC text.

    Further Hardening

    By no longer having code upgrade go through the relay chain, occupying a full relay @@ -826,6 +838,29 @@ question in a more generic way and thus could indeed open this storage facility for other purposes as well. E.g. smart contracts, so the PoV would only need to reference contracts by hash and the actual PoV is stored on validators and collators and thus no longer needs to be part of the PoV.

    +

    A possible avenue would be to change the response to:

    +
    #![allow(unused)]
+fn main() {
+enum BlobResponse {
+  Blob(Vec<u8>),
+  Blobs(MerkleTree),
+}
+}
    +

    With this the hash specified in the request can also be a merkle root and the +responder will respond with the entire merkle tree (only hashes, no payload). +Then the requester can traverse the leaf hashes and use the same request +response protocol to request any locally missing blobs in that tree.

    +

    One leaf would for example be the PVF others could be smart contracts. With a +properly specified format (e.g. which leaf is the PVF?), what we got here is +that a parachain can not only update its PVF, but additional data, +incrementally. E.g. adding another smart contract, does not require resubmitting +the entire PVF to validators, only the root hash on the relay chain gets +updated, then validators fetch the merkle tree and only fetch any missing +leaves. That additional data could be made available to the PVF via a to be +added host function. The nice thing about this approach is, that while we can +upgrade incrementally, lifetime is still tied to the PVF and we get all the same +guarantees. Assuming the validators store blobs by hash, we even get disk +sharing if multiple parachains use the same data (e.g. same smart contracts).

    (source)

    Table of Contents