EIP-0046: Atomic Transaction Chains in Mempool

eip-0046.md

@@ -0,0 +1,158 @@
+
+
+# EIP-0046: Atomic Transaction DAGs in Mempool
+
+* Author: aslesarenko 
+* Status: Draft
+* Created: 27-06-2024
+* License: CC0
+* Forking: Not Needed
+
+## Contents
+- [Description](#description)
+- [Background And Motivation](#background-and-motivation)
+- [Example Use Cases](#example-use-cases)
+- [Summary of The Proposal](#summary-of-the-proposal)
+- [Changes in the Reference Implementation of Ergo Client](#changes-in-the-reference-implementation-of-ergo-client)
+    - [UnconfirmedTransaction Class](#unconfirmedtransaction-class)
+    - [Transaction handling changes](#transaction-handling-changes)
+    - [Support in DApps](#support-in-dapps)
+    - [New API Endpoints](#new-api-endpoints)
+- [Security Considerations](#security-considerations)
+
+## Description
+This EIP proposes a new extension to the transaction processing in the mempool to support
+Atomic Transaction DAGs (ATDs) in the Ergo blockchain, where DAG refers to Directed
+Acyclic Graph. ATDs ensure that a series of chained transactions are either all included
+in a block or none are included, thus preserving the integrity and preventing undesirable
+(for DApps and L2 protocols) states on the blockchain.
+
+## Background And Motivation
+
+When a transaction is sent to the Ergo node, it is first placed into a mempool
+queue. From the mempool, the node can pick up transactions to include in the next block.
+Chained transactions (or transaction chains) are sequences where the outputs (UTXOs) of
+one transaction are immediately consumed by the next transaction in the sequence, forming
+a chain. 
+
+Although many transactions can be chained together as long as the input UTXOs (called
+Boxes in Ergo) are not yet spent, there is a problem: the default mempool procedure can
+break the chain by including only part of it in the next block. This can create
+undesirable states for dApps and L2 protocols.
+
+The solution proposed in this EIP is to introduce Atomic Transaction DAGs (ATDs), which
+extend the unconfirmed transaction data structure to include special markers, ensuring
+that miners either include all chained transactions in a block or none at all. This will
+preserve the integrity of the transaction chains and ensure consistent states on the
+blockchain.
+
+HOWEVER, it is important to note that ATDs don't guarantee atomicity when implemented as
+mempool feature only. Full implementation will require L1 protocol changes, such that ATDs
+are enforced by all miners, i.e. it is consensus level requirement, not mempool level
+optimization. From this perspective, this EIP is a first step towards full ATD support on
+L1.
+
+## Example Use Cases
+
+- **Complex DApps**: Decentralized applications (DApps) that rely on multi-step
+  transactions can ensure atomic execution, preventing intermediate states that could lead
+  to vulnerabilities or inconsistent data.
+- **Batch Payments**: DApps or services that need to process batch payments can use ATDs
+  to ensure all payments in the batch are processed together. This also includes the case
+  when the batched transactions are independent, but should be processed atomically
+  together, in which case ADT markings connect them together.
+- **Cross-Chain Operations**: Ensuring atomicity in transactions that interact with
+  multiple blockchains or off-chain components.
+- **DeFi Protocols**: Transactions across decentralized finance (DeFi) protocols can be
+  DAGed to ensure atomic execution, enhancing security and reliability. 
+  Example: 1) Withdraw from SigUSD; b) Swap on DEX; c) Send to Rosen.
+- **Simplified DApp design**: DApps can simplify their design by chaining multiple
+  transactions together without worrying about partial execution.
+- **Easier Implementation of L2 Protocols**: Layer 2 protocols can use ATDs to ensure
+  atomic execution of their transactions, simplifying the implementation and improving
+  security.
+- **Improved User Experience**: Integration with wallets like Nautilus will allow DApps to use
+  the mempool to improve user experience with transaction chaining and instant balance
+  updates.
+
+## Summary of the Proposal 
+
+Ergo node can be configured to support ATDs (after this EIP is implemented in Ergo node) to
+recognize and process the new ATDs transaction markers. The process involves:
+
+1. **Mempool Handling**: Collecting all transactions belonging to the same DAG from the
+   mempool.
+2. **DAG Verification**: Ensuring that the DAG is complete and no transactions are
+   missing.
+3. **Atomic Inclusion**: Scheduling the inclusion of the entire DAG into the next block,
+   ensuring atomicity.
+
+DApps can selectively send ATDs to Ergo nodes that announce their support for this feature,
+ensuring that their transactions are processed atomically.
+
+## Changes in the Reference Implementation of Ergo Client
+
+To support Atomic Transaction DAGs (ATDs) in the mempool, modifications are required in
+the Ergo node, specifically:
+- in the API enpoints
+- in handling of UnconfirmedTransaction in the mempool
+- wire format (network message format) of the broadcasted transaction data 
+
+The changes are described in the following sections.
+
+### UnconfirmedTransaction Class
+
+The UnconfirmedTransaction class needs to be extended with optional fields to support
+chaining of transactions. These fields include:
+
+- `chainId` -  identifier of the first transaction in the chain. It is obtained
+  by topologically ordering the transactions in the Directed Acyclic Graph (DAG) and using
+  id of the first transaction.
+- `indexInChain` - index of this UnconfirmedTransaction in the whole chain
+- `numTransactions` - the total number of transactions in the DAG.
+
+By examining these fields, the Ergo node can determine the transaction is part of a DAG
+and ensure it is processed as part of it in mempool operations (see the next section).
+
+### Transaction handling changes
+
+The mempool handling process needs to be updated to support ATDs. The main classes that
+need to be changed are ErgoMemPool, OrderedTxPool and ErgoNodeViewSynchronizer:
+- The OrderedTxPool should be able to store and collect transactions belonging to the same
+  DAG by grouping them by the new `chainId` field. 
+- The ErgoMemPool should be able to verify the DAG integrity and ensure that all
+  transactions in the DAG are either all included in the next block or none are included.
+- ErgoNodeViewSynchronizer needs to broadcast transactions with new ATDs fields (if they
+  are present) and also be able to receive and process such ATD transactions from other nodes.
+
+### Support in DApps 
+
+When a DApp wants to submit a new ATD to the blockchain, it should:
+
+- Topologically order the DAG into a list of transactions.
+- Use the `id` of the first transaction as the `chainId`.
+- Pair each transaction with the chaining fields.
+- Post each transaction individually to the node API endpoint along with the chaining
+  fields.
+
+All of this implementation details can be encapsulated in Ergo SDKs and hidden from dApp
+developers.
+
+### New API Endpoints
+
+To facilitate interaction with DApps, new API endpoints need to be created.  The
+operations supported should include posting new ATDs, retrieving existing ones, looking up
+ATDs by their identifiers, searching for ATDs based on certain criteria, and replacing
+existing ATDs.
+
+## Security Considerations
+
+- **DAG Integrity**: Ensuring that all transactions in a DAG are valid and that the
+  DAG is not tampered with.
+- **Mempool Management**: Preventing mempool spam or abuse by enforcing limits on the
+  number of transactions in a DAG. 
+- **Protocol Updates**: While this proposal doesn't require protocol update, in the future 
+    it may be possible to update the L1 protocol to support ATDs which will give better
+    security guarantees to the DApps.
+
+