---
# System prepended metadata

title: Decentralized authentication middleware

---

# Decentralized authentication middleware

The scaling discussions that have been going on are mainly around scaling financial dapps. Scaling for non-financial dapps has a different set of assumptions/requirements 

## Recommend prior read

- [A blockchain dedicated to verifying SNARKs](https://hackmd.io/RKGpyWvNRSGnkLVRsBbw0Q)

## Design principles

We aim to create a system where **anyone can easily construct the state of a dapp by fetching data from a decentralized storage network**. In essence, this is important mainly for two reasons: Censorship resistance and Hardness. Hardness, in other words, is the property that **dapp A can confidently integrate with dapp B without worrying about dapp B developers disappearing**. I would love to see hardness for non-financial apps leading to a plethora of innovative dapps, as we have seen a Cambrian explosion of innovative financial services in the DeFi ecosystem.

In this write-up, I propose two potential pathways to achieve such property.
- **Proof of payment middleware**
- **A blockchain middleware dedicated to verifying signatures and/or SNARKs**

Both paths share the same goal of creating an **authentication middleware. Through verifying signatures/SNARKs, the authentication middleware provides ownership to data hosted on decentralized storage networks.**



## Proof of payment

In principle, we only need to impose higher fees for execution than storage. A simple solution is to require data uploaded to the storage network to be accompanied by some payment that compensates for the execution of the data. For example, the full proof of a “ZK proof of membership” could have an Ethereum transaction that signs the hash of the proof along with 0.1DAI transfer to the address 0x0000… (burn address).

The fee pricing could look like:

- ECDSAVerify: 0.01DAI
- BN254Pairing: 0.1DAI

We need to rely on a stablecoin like DAI for the fee payment since there is no dynamic that users bid to miners to include their transaction into a block in our middleware. Instead,the fee goes to a burn address that knows nothing about the price of, for example, ETH. Although, an EIP-1559 style partially deterministic fee pricing mechanism could be applied to our system as well (i.e. the more fee are paid, the higher the fee for the next block).

Also, such middleware will not have a concept of time itself. So we will need to refer to the timestamp of the storage network if transaction ordering is necessary.

## A blockchain dedicated to verifying signatures and/or SNARKs

We can imagine a public blockchain that is dedicated to verifying zkSNARKs at scale, which compromises decentralization. An Ethereum-like PoS blockchain that has a higher gas limit makes sense.

One possible way to spin up such blockchain is to “re-use” the trust layer of Ethereum through [EigenLayr](https://www.layrlabs.com/). Instead of issuing our own token and bootstrapping the network of validators, EigenLayr allows us to ask Ethereum validators to also validate our chain as well. The validators will collect fees from our chain in exchange for facing the additional slashing risks that are presented by our chain.

EigenLayr is still in development so there are timeline uncertainties. But it’s definitely an innovation that expedites infrastructure development.

### 

## What is the value of such middleware?

Both of the middlewares above provide a means of execution for the data stored on a decentralized storage network. This is equivalent to [FVM](https://filecoin.io/blog/posts/what-the-fvm-unlocks/) which is the execution layer of Filecoin. **But the solutions proposed in this write-up are modular** in contrast to the monolithic design of Filecoin/FVM.

**Having modularity, we can expect other developers to build infrastructures/abstractions on top of the middleware.**

For example, we can imagine a decentralization relational database, or document (NoSQL) database that provides intuitive state management for dapp developers, **built also as a middleware.**

Such separation of concern allows the middleware to be plugged into any storage network as well. Any developer should be able to create a middleware that enables integration with any storage network.

## Sharding
It also makes sense to “shard” the middleware per app. If you operate a twitter-like dapp and want to provide integration with Guild.xyz (community management software), you can simply sync the Guild.xyz shard.

## The Middleware node

A middleware node will consist of the following modules

- A module to fetch data from the storage network. Which can be either:
    - A client implementation of the storage network it’s trying to fetch data from
    - A module to fetch data from a remote gateway of the storage network
- A module for fee payment
- A module to construct the state of a dApp according to its “ABI”.



## What the architecture could look like
Instead of thinking that the authentication middleware is a sole solution, we can imagine other middlewares to be built as well (e.g. data abstraction middlewares as described above).

![](https://i.imgur.com/X8V9MfW.png)



## Appendix
**Spinning up a storage network node**
- Arweave
    - The official Arweave client only supports synching the entire chain, and there are no other Arweave clients that I’m aware of.
- Filecoin
    - I have to deepen my understanding of Filecoin first, but it seems like Filecoin has a more rigorous protocol specification than Arweave.

**Known unknowns**

- What would the fee mechanism for the “proof of payment” version of the middleware look like?
- What are current (and failed) solutions for decentralized authentication for non-financial dapps?

**Further research**

- Deep dive into the [Lens Protocol](https://www.lens.xyz/) architecture.