Epoch Protocol Docs
Ask or search…
K
📄

Litepaper

Introduction

Decentralized applications (dApps) have transformed the way we interact with digital services, they offer greater control, privacy, and security over the apps we use and control over our data and digital assets. To interact with the network one has to use a unique type of account called an Externally Owned Account (EOA). EOAs are essential to the Web3 ecosystem as they enable users to manage their assets, make transactions, and pay for gas. But they also add a layer of complication to the web3 user experience where the users have to manage and safe keep their EOA.
No matter how much we try to improve the user experience of web3 dapps they are still limited by the current blockchain infrastructure and the critical interaction nuances.
Another significant limitation is the lack of flexibility and customization in executing transactions. In today’s world of automation and AI, we can only send transactions manually and in the succeeding blocks without any automation or triggered-based execution, which is a very primitive way of interacting with any system.
We aim to create an open network that allows users to send user operations and be creative with the conditions, timing, and method of authentication/signing for their transactions.
Our Decentralized Transactions as a Service (DTaaS) draws inspiration from the ERC-4337 account abstraction standard to improve user experience and reduce the complexity of the transaction process.

Problem Statement

In order to reach the next billion users, it is important that we improve the user experience of the web3 dapps all the way from onboarding the user to making frequent transactions on-chain while still keeping the privacy and security of self-custody wallets intact.
With the existing blockchain, infrastructure transactions are processed sequentially, meaning that users cannot specify conditions for executing transactions, such as the timing, the circumstance, and the method for signing/authentication of the transactions.
For instance, every interaction a user has with a web3 dapp has to be a transaction that the user triggers on the dapp, the transaction is then forwarded to the wallet where the user has to authenticate this transaction before it is sent to the blockchain by the dapp.
Most self-custody wallets are very limited in what they can do with transactions, the user can either approve or reject a transaction. It is not possible to pre-approve transactions, delay transactions for a later time or even use 2FA methods to authenticate.
An additional issue with self-custody EOA wallets is that you have to have the gas token to pay the gas for the chain you’d like to interact with, though this has been solved to some extent by Meta Transactions(EIP-2771), but the issue largely remains the same.
Another one of the primary issues with web3 wallet user experience is the complexity of the setup process. Traditional web applications require users to create an account with an email address and password, while web3 wallets often require users to set up a new, separate wallet with a private key and safeguard it to prevent theft and hacks. This process can be confusing and overwhelming for users who are unfamiliar with cryptocurrency and blockchain technology.
All of these issues make it difficult for developers to create dApps that offer unique user experiences and create dapps which can scale to millions of users and interactions per day.

Solution

Epoch Protocol will be a decentralized network of bundlers(EIP 4337) connected to each other using a P2P protocol and a validation layer, these bundlers will extend and have more abilities than the vanilla bundler proposed in the EIP-4337.
The protocol will make sure that users can send the transactions to any bundler(or public mempool), which will in turn be responsible for -
  • Bundling and Forwarding the transactions to the blockchain
  • Taking the user’s transaction fee from the paymaster, so that the user doesn’t have to keep and pay for the gas.
  • Storing and safekeeping the user-approved transactions in the case of a delayed or condition-based execution.
  • Validating transactions executed by the other bundlers in the network.
  • Put the proof of transaction execution on the bundler network for validation.
There are multiple moving components that will solve the above-mentioned problems.
Transaction Manager - Network Agnostic Bundler + Relayer + Executor
This Layer of our Infrastructure is essential for four different tasks -
  1. 1.
    Receiving User operations from users along with multiple execution conditions, including, time of tx execution, conditions that need to be fulfilled, chain ID, and any off-chain computation if needed.
  2. 2.
    Writing all the data to an appchain and keeping its own state in sync with the chain.
  3. 3.
    Listening to all the events of selected blocks and executing transactions whose conditions are satisfied.
  4. 4.
    Executing some off-chain code or adding some specific data to transactions to partially sign transactions and signing them.
  5. 5.
    Signing partially signed transactions after adding relevant data (Still under research).

Custom Appchain

This layer of the network is used to maintain the state and perform some extra tasks, like
  1. 1.
    Picking up a random node to listen to events of a block for a chain and execute valid transactions.
  2. 2.
    Maintaining a ledger of transactions in a private manner.
  3. 3.
    Slashing stake defaulting nodes and distributing rewards to all the task executors.

Gatekeeper contracts

This smart contract will maintain multiple checks
  1. 1.
    Functions that the user allows our services to execute.
  2. 2.
    Parameters that can be variable and fixed, and values of fixed parameters.
  3. 3.
    Holding allowances or funds that need to be used, transfer/allowances can be made in the main transaction itself if account abstracted wallets are being used.
  4. 4.
    Ability to handle partially signed transactions with different parts of transactions being signed by different parties.

Paymaster

This is a standard Paymaster from ERC4337 that will pay for the gas fee for the users if opted for this.
This will also be used to pay a gas fee for transactions on different chains.

Privacy Manager

User operation privacy is important, otherwise, it makes the entire thing prone to MEV exploits.
We have two approaches that can be used -
  1. 1.
    Proxy re-encryption - This approach will have a custom policy for decrypting tx data, and the transaction will be decrypted right at the time of sending by adding the node that is sending a transaction to the policy for decrypting transaction data.
  2. 2.
    Private state with zk verifiable data - The state of the appchain can be made private, only the participant nodes bundler will be able to read the state, without exposing the data. User operations’ existence can be verified with zk proofs.

SDK

The SDK will allow dapps and developers to connect their applications to our bundler network.

Architecture

  1. 1.
    A node of the Epoch network will be the culmination of two things, one will be the transaction manager and the other one will be the appchain node of epoch network.
  2. 2.
    Transactions will be sent to the transaction manager, and the transaction manager will write them to the appchain.
  3. 3.
    A gatekeeper contract will be deployed for each user to keep everything scope limited and each transaction will have to pass through a gatekeeper contract.
  4. 4.
    The gatekeeper contract will also ultimately charge the user a protocol fee and gas fee if paid via our paymaster.

Development roadmap

The entire thing can be built up with a multi-tiered approach.
  1. 1.
    Gatekeeper contracts that will give end users fine-grained control of the transaction’s execution conditions.
  2. 2.
    Paymaster with the ability to pay for transactions.
  3. 3.
    Transaction Manager with all the relevant features.
  4. 4.
    Appchain with basic state management and syncs with Transaction Manager.
  5. 5.
    Introducing privacy of user operations on the appchain (Needs more research).
  6. 6.
    Introducing PBS to completely eradicate MEV (Needs research and drawing inspiration from flashbots).

Use cases

Our protocol comes with an extensive range of use cases
  1. 1.
    Transaction batching, institutions, and companies can send multiple transactions that they want to send. Epoch protocol will send them in one go.
  2. 2.
    Smart Contract Automation in terms of time, on-chain, and off-chain conditions.
  3. 3.
    Sending conditional transactions based on on-chain events, it would be useful for things like Limit orders, loan refinancing, and loan liquidation.
  4. 4.
    Sending conditional transactions based on off-chain events would be useful for things like buying more eth if a specific sports team wins or any other webhook-dependent event.
  5. 5.
    Off-chain computation with partially signed transactions to claim poolTogether wins.
  6. 6.
    SIPs and AIPs.
  7. 7.
    Sending and managing supply chain transactions based on extensive conditions set around transactions.
  8. 8.
    Gas relayer.
  9. 9.
    Oracle.

Conclusion

Epoch would be a game changer to the way how people interact with the transactions, they can be agnostic for all the chains in terms of sending transactions and paying gas. Users will get to be creative with the way how they want their transactions to be executed in terms of time, on-chain and off-chain conditions, doing some off-chain computation before executing transactions, batching transactions, and a lot more.