Skip to main content

Whitepaper

Index

1. Abstract

2. Introduction

3. Architecture

4. Example use case

5. Security

6. Citations

1. Abstract​

Metalayer is a decentralized, permissionless, and Turing-complete computation platform that enables the secure execution of arbitrary code and attestation of the results. Validators in Metalayer network execute computations within isolated containers and produce attestations using a secure threshold signature scheme. By leveraging a native proof of stake token and re-staking mechanisms, Metalayer provides robust economic security for decentralized applications (dApps) and protocols across any blockchain network. Metalayer empowers developers to build a wide range of dApps, from oracles and zero-knowledge rollups to AI model inference, with the assurance of high economic security.

2. Introduction​

Decentralized networks have proved to be useful for various use cases. Novel networks have been created to perform different kinds of computation, such as zero-knowledge rollups, optimistic rollups, video encoding, AI model inference, etc.

Creating such decentralized networks is an involved process. It requires choosing consensus algorithms, developing network nodes, securing buy-in from node operators, and launching a native utility token to provide economic security. Bootstrapping the network's economic security is challenging since it essentially depends on the native token's market cap, which is subject to market forces and out of the developers' direct control.

The creation of various restaking protocols attempts to solve the problem of bootstrapping economic security. These networks allow existing staked tokens, such as staked Ether, to provide economic security to other networks. Since Ether's market cap is one of the highest of any other blockchain token, the economic security offered is also relatively high. Developers can build protocols utilizing restaking protocols to solve the issue of bootstrapping economic security.

However, it comes with a new set of challenges. Utilizing restaking protocols may require approval from the restaking protocol stakeholders if it is not permissionless. It may require opt-in from the restaking protocol operators. They may demand multiple security audits and extra-protocol incentives that may not be feasible for a nascent network.

Operators may hesitate to opt into new networks due to security concerns. The network nodes may act maliciously, hurting the operator's infrastructure. Or they may behave in a byzantine manner and cause the operator's stake to be slashed. For these reasons, restaking protocols provide a permissioned, non-homogenous platform that is difficult to utilize.

Metalayer is a decentralized, homogenous, permissionless, universal computation and data verification platform. As the network is fully permissionless, computations are performed by all the operators without requiring any opt-in. Metalayer is a proof-of-stake network whose native token is used to secure the network and encourage honest behavior. Metalayer also leverages restaking platforms to provide high economic security to all the applications utilizing Metalayer. Metalayer provides a secure arbitrary code execution environment that can be used to verify a client network's calculations in isolated containers securely. Metalayer is an attestation network, and it is isolated from byzantine activity in the client network. Metalayer operators do not risk slashing due to any issues in the client's code.

2.1 Verification Methods​

In decentralized networks or even centralized trustless networks, such as rollups, the network's validators can act in a byzantine or malicious manner. Hence, computations must be independently verified, and corrective actions must be taken in case of malicious behavior. There are various ways to verify and perform corrective actions in networks.

2.1.1 Redundant Computation​

Every node verifies the entire network's computation in decentralized blockchain networks such as Ethereum. While this is effective, the computation is highly redundant and uses a lot of computation resources.

A portion of the network's total stake limits these networks' economic security.

2.1.2 Computation Verification Using Dispute Bonds​

Another method is to use dispute protocol, where the challenger posts a security bond and challenges computation performed by a malicious validator. All other validators verify the computation and can blame and slash the blamed validator if it is indeed malicious. Else, the challenger's bond is slashed.

Like the previous method, a portion of the network's total stake limits its economic security.

2.1.3 Zero-knowledge Proofs and Other Cryptographic Verification Methods​

In the case of zero-knowledge proof-based protocols such as rollups, cryptographic methods such as zk-SNARKS are used to verify the computation of the rollup sequencer. Since these proofs are impossible to forge, the security of these rollups entirely depends on the economic security of the Layer One chain it is settled on, such as Ethereum Mainnet.

However, these methods also have some limitations. Computing and verifying these proofs is quite expensive. Verifying them may cost up to 1 million gas on Ethereum's mainnet, which is prohibitively expensive for most developers. This prohibitive cost also limits the use cases for such methods.

Proof/SignatureApproximate Gas Cost on Ethereum
Zk STARK1,000,000
Groth 16250,000
KZG Commitments193,084
BLS113,000
ECDSA30,000
Figure 1: Approximate gas verification costs of various cryptographic primitives on Ethereum

Metalayer can be used to verify zero-knowledge proofs as well as any other cryptographic proofs or signature schemes. These networks can utilize Metalayer's economic security for fast and secure verifications.

As can be seen from the above, various methods exist for verifying computation in decentralized networks. However, they are limited by either the network's economic security or cost significant fees for verification, such as in the case of zero-knowledge proofs.

Metalayer can solve these problems by providing an independent decentralized network of nodes that can perform arbitrary computations and verify the computation of these networks. These networks can boost their economic security by relying on a network of higher economic security, such as Metalayer.

3. Architecture

Metalayer Network consists of:

  1. Metalayer node
  2. A set of solidity smart contracts
  3. Metalayer chain, we will call this the "native chain."

3.1 Cryptographic Methods​

We want a decentralized group of validators to perform computations and attest the results independently. For portability reasons, we would like the nodes to perform a single signature collaboratively, which can be verified on a large number of networks.

While BLS signatures can be used, they are more expensive to verify than ECDSA signatures. Hence, we will use an ECDSA-based Threshold Signature Scheme, which is inexpensive to verify and more widely supported.

3.1.1 Reasons for Using a Threshold Signature Scheme​

Threshold Signature Schemes (TSS) offer several advantages for secure distributed message signing in various applications. Some primary reasons for choosing TSS include:

  1. Enhanced security: TSS reduces the risk of single-point failure by distributing signing authority among multiple participants, ensuring system security even if some keys are compromised.
  2. Fault tolerance: TSS allows the system to function even if some participants become unavailable as long as the threshold is met.
  3. Reduced trust requirements: Trust is distributed among participants, reducing the risk of collusion or misuse of power by a single party.
  4. Confidentiality: TSS maintains the confidentiality of private keys by using secret sharing techniques and partial signatures during the signing process.
  5. High-security access control: A high threshold parameter ensures critical decisions require approval from a large number of participants, enhancing security and protecting sensitive information.
  6. Scalability: TSS accommodates a large number of participants, improving security and enabling flexible access control policies.
  7. Broad applicability: TSS is well-suited for various applications, including distributed systems, cryptocurrency wallets, secure voting systems, and blockchain platforms.

Threshold Signature Schemes provide a robust, flexible solution for secure distributed message signing. They address the challenges of traditional single-signer systems and enable secure multi-party collaboration.

3.1.2 Reasons for Using the GG20 Algorithm for Performing Threshold Signatures​

We will use the gg20^[1]^ algorithm for threshold signatures for the following reasons:

  1. Economic efficiency: GG20 reduces the need for costly hardware-based security solutions, such as Hardware Security Modules (HSMs), by distributing trust among multiple participants in a blockchain network. This can minimize infrastructure costs and lower the entry barrier for organizations and developers seeking to implement secure signing solutions compatible with ECDSA-based blockchains.

  2. Communicational efficiency: GG20 is designed to minimize the amount of data exchanged between participants during the signature generation process. Efficient communication is essential for maintaining low latency in blockchain systems, ensuring timely completion of the signing process, and supporting high transaction throughput.

  3. Computational efficiency: GG20 employs efficient cryptographic primitives and optimizations, such as Pedersen commitments and zero-knowledge proofs, to minimize the computational overhead of the signing process. Faster signing and verification times are crucial for large-scale blockchain systems with numerous transactions or operations requiring signatures, as they help maintain network performance.

  4. Native support on a large number of platforms: GG20 is a versatile solution that can be implemented on various blockchain platforms, including Bitcoin, Ethereum, and other ECDSA-based networks. By leveraging the ECDSA cryptographic standard, GG20 can be easily integrated with widely adopted blockchain systems that require secure distributed message signing. The compatibility and adaptability of GG20 make it a desirable choice for developers and organizations seeking to build secure and efficient signing solutions for blockchain applications.

3.2 Information Flow​

The general information flow is described below.

Figure 2: Information flow

  1. Client protocol requests data through the inbox contract

  2. Metalayer validator nodes will:

    a. Fetch the request from the requesting chain

    b. Fetch data URLs, if provided

    i. If a container is provided in the request, execute the container and sign the results.

    ii. Else, sign the response from the URLs

    c. Otherwise, sign the request message.

  3. Validator nodes sign the results using the gg20 Threshold Signature Scheme

  4. Validator nodes broadcast the attestation to the native chain

  5. The user fetches the message and the attestation and broadcasts it on the desired target chain.

  6. The results and attestation are verified on the target chain.

3.3 Oracle Cycle​

Figure 3: Metalayer oracle cycle

One oracle cycle is called an epoch. A dynasty consists of multiple oracle cycles, and the actions during each cycle depend on the network's state. Let us review each state's actions.:

  1. Validator Selection

    a. Validators calculate the iteration using the process described in 3.2.3.1.3.2 Churn-In.

    b. We churn out validators from the previous set before churning in new validators to replace them.

    c. This mode runs for a set number of epochs. At the end of the epoch limit, if we have N validators in the set, we move to the next mode; otherwise, we wait until we reach N validators.

  2. Signer Creation

    a. The selected N validators generate the keygen public address.

    b. Each validator has to send an attestation of the keygen address on-chain. The keygen address with T + 1 or more attestations becomes the attested signer address for the dynasty.

    c. The previous validator set has to prepare a threshold signature on the attested keygen address. This signature will denote the power transfer of the prior validator set to the new one set in the protocol.

    d. Once the signature is verified and validated, the protocol confirms the attested keygen address and is ready to sign blocks.

    e. We move to Signing mode once the above steps are completed in an epoch.

  3. Signing:

    a. Fetch data and send a commitment of that data to the contract.

    b. Once there is consensus on the data to be signed, prepare a threshold signature.

    c. Send the signature signed by the TSS public key on the data, and upon confirmation of the block, a block reward will be given randomly to one of the selected validators.

    d. The current validator set follows this process till the end of signer creation mode in the next dynasty when the new validator set takes over.

3.4 Metalayer Node​

Metalayer consists of operators running Metalayer node and staking the native token. They may also utilize one or more restaking platforms to restake other assets.

The Metalayer nodes perform the following workflow.

3.4.1 Fetch requests from inbox request contract.​

As Metalayer is chain agnostic, the inbox contract may be deployed on multiple networks. In this example, let's assume the Metalayer inbox contract is deployed on network A. Protocol B creates a request in this contract. Metalayer nodes will periodically check the inbox contract on all supported networks and read the requests.

The requests will contain some or all of the following information.

a. Container Image URL​

If the request requires a custom container image, the container image URL must be provided. If no container link is provided, the nodes will simply fetch the Source URLs and attest the results.

b. Input Parameters​

Any input parameters are to be provided to the container.

c. Source URLs​

URLs for source data from where information is to be fetched. This data will also be provided to the container as input parameters.

3.4.2 Fetch The Container Image​

If a container image is provided in the request, the image will be fetched for the URL provided.

3.4.3 Fetch Data from Source URLs​

The source URLs will be fetched to gather the requested data.

3.4.4 Execute the Container​

If a container URL is provided, it will be executed securely. Due to security reasons, the container will be restricted, and limited privileges and resources will be provided.

The following restrictions may apply.

a. No internet access

b. No access to the host operating system and disk.

c. Limited memory and CPU cores.

d. Limited execution time

After execution, the node commits the result to Metalayer network, and the container is deleted.

Multiple such containers can be executed simultaneously, as the resources provided to each container are limited.

3.4.5 Perform a Threshold Signature​

Metalayer's validators use the gg20 protocol specified in section 3.2.1 to perform a threshold signature to attest the execution results. If no container URL is provided, the data fetched from data source URLs will be attested.

3.4.6. Publish the Attestation​

The threshold signature and the result are published on the smart contracts. The same result can be validated on any of the supported networks.

3.5 Smart Contracts​

Metalayer smart contracts are written in solidity and can be deployed on any EVM-compatible blockchain. Solidity is a popular programming language for smart contracts, and many blockchains, including Ethereum, support it.

Metalayer smart contracts consist of two groups.

  1. Metalayer consensus algorithm is a set of smart contracts deployed on an EVM-compatible blockchain. We will call this the native chain. Validators will rewarded for attesting and signing requests on Metalayer consensus layer, and any malicious behavior will be penalized.

  2. An inbox contract deployed on supported chains. This contract allows requests to be made to Metalayer and validates attestations received from Metalayer.

Figure 4: Non-native chain Smart contracts

3.5.1 Non-Native Chain Smart Contracts​

3.5.1.1 Inbox Proxy​

Clients will query the results of their requests from the result manager through the Result proxy.

3.5.1.2 Inbox Contract​

Allows the creation of requests for the oracle. Requests can be created, but their confirmation will depend on the finality of the chain where the request has been made.

It also allows verification of attestation performed by Metalayer. Once the signature is verified, the results of each request will be stored in the contract.

Client applications or users can request to fetch and attest any data on a supported blockchain. The data does not need to be on the native chain.

The request is created by sending a request transaction to Metalayer and paying the transaction fees to the network.

Format of the request:

Request = [message sender address, Requesting chain ID, container URL, container params, Source URLs, target chain ID, fee, confirmations]

3.5.2 Native Chain Smart Contracts​

This is the chain where Metalayer protocol will be deployed.

Figure 5: Native chain smart contracts

3.5.2.1 Selection Manager​

This is the main contract where validator selection for keygen, keygen attestations, and power transfer occurs. Depending on the network's current mode, it also decides what course of action other managers have to take.

3.5.2.2 Stake Manager​

Stake Manager handles staking, delegation, unstaking, giving out rewards, slashing, and jailing validators.

3.5.2.3 Blame Manager​

Blame Manager manages all the blame attestations and the aftermath after consensus on a particular blame.

3.5.2.4 Block Manager​

Block manager handles commitments of messages to be signed to create a block, Signature verifications, and Block confirmation.

3.5.3 Native Chain Workflows​

The following workflows happen on the Native chain of Metalayer.

  1. Stake
  2. Delegate
  3. Validator Selection
  4. Keygen
  5. Signing
  6. Blame Process

3.5.3.1 Stake​

Metalayer will have multiple staking modules, each representing either one of the Restaking protocols or Native Metalayer staking. Native Metalayer staking allows anyone to stake in native metalayer tokens to be eligible to become a validator. Each staking module will be assigned a certain base weight. Depending on the amount a validator may have staked in the module, the stake amount will be multiplied by the base weight, resulting in the stake weight of the validator in the staking module. The summation of weights from all the staking modules will be the overall stake weight of a validator.

As long the stake weight of the validator is above the minimum stake weights specified by the protocol, the validator can stake any amount they wish to. Each validator has equal signing power in the network. To get a higher signing power in the network, validators can stake multiple times through different accounts.

3.5.3.2 Delegate​

Validators or other token holders can delegate additional tokens to the validators. While this will not increase the signing power of the validator, it will increase the chance of their delegated validator being selected in the active set, thereby making the validator eligible to earn block rewards for the dynasty. It will also provide a buffer in case of penalties.

3.5.3.3 Validator Selection​

Validators are selected using the churning process, which can be divided into two sub-processes to complete the selection of validators:

  1. Churn-Out
  2. Churn-In
3.5.3.3.1 Churn-Out​

Instead of starting the selection process from scratch, some validators selected in the previous dynasty are retained and chosen for the current dynasty, and the rest are churned out. The mechanism to churn out validators follows a specific hierarchy based on the following:

  1. Validators being banned by the network
  2. Validators wanting to withdraw and leave the network
  3. Random selection of validator from previous dynasty active set
  4. Poor performing validators

One thing to note is that in a churning-out event, the protocol will churn out a maximum of 1/3rd of validators selected in the previous dynasty for the current dynasty. Churned-out validators will not be allowed to participate in the current dynasty's validator selection process.

3.5.3.3.2 Churn-In​

During the validator selection phase, any validator can participate in the validator selection process, provided the validator's share of the staked amount is above the minimum stake required. A sorted list of N-selected validators is pseudorandomly but deterministically calculable for each dynasty. The probability of being higher up the list is directly proportional to the stake of each validator.

The following algorithm is used to prepare the validator priority list:

  1. Roll an N-sided fair die

Si = ⌊PRNG(n || Seed) ∗ St⌋

Where,

Si = Validator ID

PRNG = Pseudo-Random Number Generator function, which utilizes the provided salt

n = nonce

Seed = seed for PRNG

St = Total number of validators in the protocol

Repeat the above step till the validator gets Si, which is equal to their validator ID.

  1. Toss a biased coin where bias is the ratio of the stake of the validator and the stake of the largest validator in terms of stake.

S / (Sh) >= PRNG(n || Si || Seed)

Where,

S = Stake of the validator

Sh = Stake of the validator with the highest Stake

  1. The above steps are repeated with increasing iteration( n =1,2,3,4,...). Whenever the second statement is considered true, validators send over that iteration number for the current dynasty, and the validator is added to the validator set for that dynasty.

  2. The lower a validator's nonce value, the more likely it will be selected for the current dynasty, which is finalized when the validator selection mode ends. Proposals will be stored on-chain as a list of increasing nonce, with a max length capped at N.

3.5.3.4 Keygen​

The keygen phase will occur once the validator set has been finalized at the start of every dynasty. A dynasty is defined as a fixed period of epochs determined at deployment time.

  1. Check smart contracts to get a list of active validators.
  2. Broadcast keygen message to eligible validators.
  3. Create and submit the threshold public key/signer address to the blockchain. Any active validator can submit the key. Only a unique set of potential public keys and the number of active validators reporting that key will be saved.
  4. The signer address with the highest number of votes will be selected as the attested but not yet confirmed signer address for this dynasty as long as t+1 active validators report that key. If this condition fails, the keygen process fails, and it is restarted with a different group of validators.
  5. Once an attested signer address exists, the previous validator set creates a signature to transfer power to the attested signer address with a message of the following format:

message=[version, current epoch, dynasty parameters, the new attested keygen address]

  1. The attested signer address is then confirmed and ready to sign blocks.

  2. The administrator does this signature for the first dynasty or in case of emergency.

3.5.3.5 Signing Mode​

In this state, the following actions take place.

3.5.3.5.1 Fetch the Requests​

The validators fetch the requests "confirmed" on the Request chain. The confirmation time/blocks depend on the chain, and the governance mechanism decides it.

3.5.3.5.2 Execute the Requests​

Once Metalayer Validators fetch the confirmed requests, Compute requests require the validator to perform computation and get the result. Message Requests require validators to pick up the message from the data source and attest that as a result.

3.5.3.5.3 Commit the data​

Once the validators have the results of each request, selected validators will start committing their results in a FIFO order. If a result receives a threshold number of commitments from the selected validators, a request will reach consensus and be ready to be signed.

3.5.3.5.4 Perform threshold signature​

Metalayer validators will pick up requests in chronological order in which they reached a consensus and create a message with the following format:

message=(version,epoch,requestIds queried[], their corresponding values[])

The validators coordinate to perform a t-of-n ECDSA (and EDDSA) threshold signature on the constructed message to attest to the observed data.

3.5.3.5.5 Finalize Block​

A block consists of the following format:

Block =[message=(version, epoch,requestIds[], values[])] [t-ECDSA signature, t-EDDSA signature]

Once the signature is verified and validated, the block is created with the above format, and a block reward is given out to one of the selected validators randomly using PRNG (Pseudo-Random Number Generator).

3.5.3.6 Blame Process​

Blame has a separate threshold, and once that threshold is reached, the blame goes through, and penalty points are given out to the blamed nodes. Accruing penalty points affects whether the validator will be churned during validator selection. If a validator has accrued the maximum penalty points, it means the validator is to be banned, churned, and jailed. If a validator breaches the penalty points threshold, the validator is termed a poor-performing validator and will be churned based on the churning hierarchy.

Four types of blame can go through which are:

  • Keygen Unresponsive: Nodes are blamed if they are offline during keygen. Blamed nodes are given maximum penalty points but are not slashed.
  • Keygen Failure: Nodes are blamed if they cause the keygen process to fail. Blamed nodes are given maximum penalty points and are slashed.
  • Signing Unresponsive: Nodes are blamed if they are offline during signing. Blamed nodes are given penalty points enough to reach the threshold but are not slashed.
  • Keygen Failure: Nodes are blamed if they cause the keygen process to fail. Blamed nodes are given maximum penalty points and are slashed.

3.5.4 Broadcast to The Target Chain​

The client broadcasts the message and the attestation to the target chain and bears the transaction fees for this action.

The signature verification smart contract on the target chain verifies the message and attestation. If the message and corresponding attestation are valid, they are "confirmed" on the target chain. The client application can query the verification contract to check the message's validity.

Figure 6: Attestation Verification

3.5.5 Slashing Conditions​

Anyone can produce evidence of malicious behavior at any time. This can result in slashing for validators and rewards for the bounty hunter.

3.5.5.1 Double Signing​

An alternative message signed by the threshold public key can be used to prove double signing.

Since it is a clear sign of malicious behavior, which can be dangerous, a strict penalty will be applied to all the validators in case of incorrect signing. The dynasty will end, and a new dynasty will start along with the keygen process.

3.5.5.2 Non-existent Info on Native Chain​

If a block is directly sent to the destination chains and no signature exists on the native chain for that epoch/dynasty, the entire validator set responsible will be penalized.

3.5.5.3 Keygen Failure​

The scenarios where a node can be slashed for keygen failure are:

  1. If we don't receive a message or receive the wrong message from nodes, keygen fails and faulty nodes are blamed.
  2. If keygen doesn't complete within the epoch, the responsible nodes are blamed.

3.5.5.4 Signing Failure​

The scenarios where a node can be slashed for signing failure are:

  1. If the selected leader isn't reachable, then the leader is blamed.
  2. If we don't receive a message or receive the wrong message from a node.
  3. If signing doesn't complete within the epoch, we blame the nodes who haven't responded.

4. Example use case

As Metalayer is a Turing-complete platform, developers can execute any arbitrary code in Metalayer VM and verify execution. Hence, Metalayer can solve not just current potential use cases but also unknown future use cases.

4.1 A Verification of Decentralized Oracle Network​

Let's consider the use case of a proof-of-stake Decentralized Oracle Network, "DON." The network's validators stake their native token and provide price feeds for various assets.

Since the network is secured by the native token, which has a relatively low market cap, it suffers from low economic security. The project can benefit from deploying on Eigenlayer and utilizing Ethereum's large economic security. However, considerable effort will be required to develop the network from scratch and secure buy-in from Eigenlayer, their operators, etc.

Here is how Metalayer can help boost DON's economic security. DON can continue working independently, and Metalayer can act as an independent third party verifying the execution of the DON.

Metalayer can verify the Oracle results through one or more price APIs and attest the results if they are within permissible limits. With this attestation, the Oracle results can be deemed "confirmed." If the results deviate significantly from the "true" value, these attestations can be used to slash the offending validators on the DON.

Figure 7: Example use case: verification of results of a decentralized Oracle network

As can be seen from the above example, the Cost of Compromise (CoC) of the above network is the same as the CoC of Metalayer. As Metalayer relies on restaking protocols that provide high economic security, the DON also inherits high economic security using Metalayer.

4.2 A zero-knowledge rollup getting fast finality without on-chain verification​

Metalayer is a Turing-complete execution platform that can be used to verify zero-knowledge proofs such as SNARKs or STARKs.

As execution happens off-chain in Metalayer, verifying the zero-knowledge proof can happen off-chain quickly and inexpensively. Metalayer nodes can independently verify the proof and provide the attestation to confirm the L2 rollup block.

5. Security​

Arbitrary code written by clients is executed in secure, isolated containers with no internet access. The containers are also provided with limited resources and execution time. In this way, any arbitrary code can be executed securely without any potential harm to the operators. Operators fetch any requested data from the internet before executing the binary and provide it at runtime.

6. Citations​

  1. gg20, UC Non-Interactive, Proactive, Threshold ECDSA with Identifiable Aborts https://eprint.iacr.org/2021/060.pdf