Muon’s Shield Server

A Complementary Security Measure to Enhance the Threshold Network

Robert Wallace
Muon
4 min readJan 30, 2023

--

In Muon, ecosystem-security is one of our highest priorities. To address the needs of different protocols and users, our tech team has designed a security strategy consisting of three modules: Threshold Network, Optimistic Network, and Shield Server. The first module was discussed in the Threshold Signature Scheme article. This follow-up in the series details a further security measure that has recently been released on Muon: the Shield Server.

(Our readers should note that as the Optimistic Network is not yet implemented, the description below is limited to the present implementation of Shield Server; that is, how it works beside the Threshold Network. There will be minor differences in the procedure in the final architecture with all the three modules in place.)

Threshold Network & Subnets

As mentioned in the TSS article, Muon’s use of a network of nodes that generates Threshold signatures- called the Threshold Network- allows numerous nodes to collaborate off-chain to sign data feeds that can be verified at the gas-cost of one single signature. Muon’s Threshold Network is implemented in a way that allows the assigning of a random subnet of nodes to each Muon app for a predefined period of time. This is why Muon is a decentralized and scalable oracle network.

Threshold Signature Scheme is pioneering innovation and promisingly secure. However, it has a new and complex cryptographic algorithm and some may find this a concern. Thus Muon recommends that dApps make use of a Shield Server signature in addition to the threshold one.

An Additional Protective Measure

A Shield Server refers to a server that is owned and run by the dApp that has integrated with Muon. It prevents manipulated data from being processed by the dApp through revalidating the data returned from the Threshold Network.

How It Works

Instead of sending a request directly to the Threshold Network, an app can send one to its own server or a server it trusts called the Shield Server. This server checks the validity of the request, and forwards it to the Threshold Network. Having received the signed data from the Threshold Network, it independently fetches the data and then compares the result with the signed data.

Simple Illustartion of Shield Server Signature
Requesting Data from Muon: Threshold Network & Shield Server (Simple Illustration)

If the data received by the Shield Server and Threshold Network are the same, the Shield Server sends it to the dApp client along with two signatures: its own and the Threshold’s. But if the Shield Server’s obtained data differs from that of the Threshold Network, the Shield Server does not verify the data; that is, it returns a “failed” response.

This enables apps to be ensured of the reliability of the data because it is signed by both the Threshold network, and their own server. Moreover, the implementation of the Shield Server is much simpler compared to the nodes in the Threshold Network. This raises the Shield Server’s security because even if there is a bug in the complex implementation of Threshold Nodes, the system remains secure.

The following diagram illustrates the procedure.

Requesting Data from Muon: Threshold Network & Shield Server

Best Practices

To get the most out of the Shield Server, dApp’s are advised to put the following into practice:

  • A security risk that threatens Muon apps is that trusted 3rd party RPCs such as Infura, Ankr or The Graph may be vulnerable to hacks. To address this issue, Shield Servers had better not depend on such RPCs for their input. Rather, it is recommended that they run their own Ethereum, sidechains, and graph nodes. If this is done, the procedure will be modified as shown below:
Requesting Data from Muon: Threshold Network & Shield Server (with a Local Host)
  • Although using a Shield Server signature secures the app against incorrect data feeding, downing of the Shield server results in the system’s halting. So it is recommended that projects use more than one Shield Server to avoid the risk of a single point of failure.

This protective measure covers the risks TSS might encounter and makes data feeds from the Muon network more secure. However, Muon has not stopped there and a stricter security measure is in the works. Stay tuned for more developments to come.

To learn about how to run the Shield Server, see here.

Pion is the Muon ecosystem’s Canary and first mainnet. It is a chain-independent and stateless DON (Decentralized Oracle Network) that enables dApps to make their off-chain components decentralized. By incorporating Pion (by Muon), the manner in which decentralized applications store, process, and access data will be fundamentally transformed.

Run a Pion node.

Twitter | Telegram | Discord | Website | Medium | GitBook | Developer’s Guide

--

--