add hypermap-cacher

hyperware-wit/hypermap-cacher:sys-v0.wit

@@ -0,0 +1,69 @@
+interface hypermap-cacher {
+    // Metadata associated with a batch of Ethereum logs.
+    record logs-metadata {
+        chain-id: string,
+        from-block: string,
+        to-block: string,
+        time-created: string,
+        created-by: string,
+        signature: string,
+    }
+
+    // Represents an item in the manifest, detailing a single log cache file.
+    record manifest-item {
+        metadata: logs-metadata,
+        is-empty: bool,
+        file-hash: string,
+        file-name: string,
+    }
+
+    // The main manifest structure, listing all available log cache files.
+    // WIT does not support direct map types, so a list of key-value tuples is used.
+    record manifest {
+        // The key is the filename of the log cache.
+        items: list<tuple<string, manifest-item>>,
+        manifest-filename: string,
+        chain-id: string,
+        protocol-version: string,
+    }
+
+    record get-logs-by-range-request {
+        from-block: u64,
+        to-block: option<u64>, // If None, signifies to the latest available/relevant cached block.
+    }
+
+    // Defines the types of requests that can be sent to the Hypermap Cacher process.
+    variant cacher-request {
+        get-manifest,
+        get-log-cache-content(string),
+        get-status,
+        get-logs-by-range(get-logs-by-range-request),
+        // // Request to trigger a cache update manually (optional, primarily timer-driven).
+        // trigger-cache-update,
+    }
+
+    // Represents the operational status of the cacher.
+    record cacher-status {
+        last-cached-block: u64,
+        chain-id: string,
+        protocol-version: string,
+        next-cache-attempt-in-seconds: option<u64>,
+        manifest-filename: string,
+        log-files-count: u32,
+        our-address: string,
+    }
+
+    // Defines the types of responses the Hypermap Cacher process can send.
+    variant cacher-response {
+        get-manifest(option<manifest>),
+        get-log-cache-content(result<option<string>, string>),
+        get-status(cacher-status),
+        get-logs-by-range(result<string, string>),
+    }
+}
+
+world hypermap-cacher-sys-v0 {
+    import sign;
+    import hypermap-cacher;
+    include process-v1;
+}

hyperware-wit/process-lib.wit

@@ -0,0 +1,5 @@
+world process-lib {
+    import sign;
+    import hypermap-cacher;
+    include lib;
+}

hyperware-wit/sign:sys-v0.wit

@@ -0,0 +1,61 @@
+interface sign {
+    use standard.{address};
+
+    variant request {
+        /// Request to sign the message given in blob with net key.
+        ///
+        /// lazy-load-blob: required; the message to sign.
+        net-key-sign,
+        /// Request to verify the message given in blob with net key.
+        ///
+        /// lazy-load-blob: required; the message to verify.
+        net-key-verify(net-key-verify-request),
+        /// Request to transform the message to the form that is signed with net key.
+        /// For use by outside verifiers (net-key-verify transforms naked message
+        /// properly under-the-hood).
+        ///
+        /// lazy-load-blob: required; the message to transform.
+        net-key-make-message,
+    }
+
+    variant response {
+        /// Response containing the net key signature in blob.
+        /// The source (address) will always be prepended to the payload.
+        /// The source (address) of sign:sign:sys will also be prepended.
+        /// Thus the message signed looks like
+        /// [sign-address, address, blob.bytes].concat()
+        ///
+        /// Using request::net-key-verify handles the concatenation under-the-hood,
+        /// but verifying the signature will require the proper transformation of
+        /// the message.
+        ///
+        /// lazy-load-blob: required; signature.
+        net-key-sign,
+        /// Response: whether the net key signature is valid.
+        ///
+        /// lazy-load-blob: none.
+        net-key-verify(bool),
+        /// Response containing modified message in blob.
+        /// The source (address) will always be prepended to the payload.
+        /// The source (address) of sign:sign:sys will also be prepended.
+        /// Thus the message signed looks like
+        /// [sign-address, address, blob.bytes].concat()
+        ///
+        /// Using request::net-key-verify handles the concatenation under-the-hood,
+        /// but verifying the signature will require the proper transformation of
+        /// the message.
+        ///
+        /// lazy-load-blob: required; the transformed message.
+        net-key-make-message,
+    }
+
+    record net-key-verify-request {
+        node: string,
+        signature: list<u8>,
+    }
+}
+
+world sign-sys-v0 {
+    import sign;
+    include process-v1;
+}

src/eth.rs

@@ -318,6 +318,11 @@ impl Provider {
             request_timeout,
         }
     }
+
+    pub fn get_chain_id(&self) -> u64 {
+        self.chain_id
+    }
+
     /// Sends a request based on the specified [`EthAction`] and parses the response.
     ///
     /// This function constructs a request targeting the Ethereum distribution system, serializes the provided [`EthAction`],