Swamp: A Peer-to-Peer Protocol for Sending Ethereum Transactions

Evgeny Medvedev
5 min readDec 12, 2017

This is a parody on the many ICO whitepapers aiming to highlight the absurdity of the solutions proposed by them — the solutions that don’t really solve any problem.

Abstract

We present a peer-to-peer methodology for sending Ethereum transactions on the Ethereum blockchain. First, we outline the limitations of pure blockchain and offer a strong alternative in peer-to-peer transaction sending: off-chain negotiation and on-chain broadcasting. We then describe a protocol through which parties are able to signal to others their intent to send transactions. Once connected, counterparties freely communicate their intents and transmit transactions among themselves. During this process, parties may request transaction fees from an independent third party oracle to verify accuracy. Finally, we present an Ethereum smart contract to broadcast transactions on the Ethereum blockchain.

Introduction

The number of transactions on Ethereum over the past twelve months has increased aggressively as more and more use cases are implemented as smart contracts. It is our thesis that this trend will continue into the future; as such we believe this growth will augment the demand to broadcast even more transactions to the blockchain. Blockchains are not without inherent limitations, many of which can be mitigated by the design decisions outlined in this paper. We seek to provide an alternative to pure blockchains by specifying a set of protocols that unlock anonymity and scalability and free the Ethereum ecosystem to progress without such limitations.

Blockchain Limitations

Blockchain is open, and everyone sees everything. Thus, blockchain has no real anonymity. It offers pseudonymity instead. Some disclosure may be tolerable for individuals, but it is deadly for companies. All of their contracting parties, sales, customers, account amounts become public. Financial transparency is perhaps one of the largest disadvantages of using blockchains.

Blockchains are not scalable. If each network node does the same thing, then the bandwidth of the entire network is the same as the bandwidth of one network node. The Ethereum network is capable of processing a maximum of 10 transactions per second. Aside from that, Ethereum blockchain transactions are recorded only once every 15 seconds. To increase payments security, it is standard practice to wait 5 minutes more after each new record appears. Given the transaction processing speed, significantly increasing the number of active users simply isn’t possible.

Blockchains are expensive. Every transaction incurs a fee and the average transaction fee is climbing higher constantly. If this trend continues into the future the fees will become so high that no one will be able to afford it which will result in the ecosystem stagnation.

Peer-to-peer (P2P)

Alternatively, peer-to-peer communication enables individual parties to send transactions with each other directly. Most of the transactions we make day to day are peer-to-peer: buying coffee at a cafe, selling shoes on eBay, or buying cat food on Amazon. Because these are private transactions between people or businesses, each party knows and ultimately chooses with whom they transact.

Peer-to-peer transaction sending scales. Transactions are transmitted between individual parties and are “one and done” as opposed to transactions on the pure blockchain.

Peer-to-peer transactions are private. Once two parties have found and chosen to communicate with each other, no third parties are required to negotiate. The communication between these parties remains private for the duration of the negotiation, removing the opportunity for other parties to act on transaction behavior. Only when the transaction is submitted to the blockchain will it become public knowledge.

Peer-to-peer transactions are fair. Because transactions are created and transmitted directly between two parties, no outside participants can have an advantage. As long as they are working with multiple independent parties, participants can get transaction fees that are comparable to or better than what they would achieve on a pure blockchain.

The scalability, privacy, and fairness constraints imposed by pure blockchains have necessitated an alternative. Today’s Ethereum ecosystem needs an open peer-to-peer solution for transaction sending.

Introducing Swamp

Swamp is a protocol to facilitate a true peer-to-peer ecosystem for sending transactions on the Ethereum blockchain. The following is an extensible specification that supports efficient counterparty discovery and negotiations. These protocols are intended to become a foundation for the peer-to-peer ecosystem and to accelerate Ethereum ecosystem growth. By publishing this paper and opening for discussion, we seek comments from ecosystem stakeholders with the aim to produce high-quality protocols to enable a wide variety of real-world applications.

Peer Protocol

With only a few messages passed between counterparties, transactions can be negotiated quickly, fairly, and privately. For the purposes of this document, a Node is the party that creates a transaction, and a Miner is the party that mines a block. Fee Oracle is the node that provides the fair fee for other parties. Because each party is a peer, any party can assume the role of Miner, Node or Fee Oracle at any time.

The core protocol is sequenced in the following diagram. The Node, Fee Oracle and Miner perform transaction negotiation off-chain. The Contract below is an Ethereum smart contract, which the Node calls when ready to submit the transaction on the blockchain.

  1. Node asks for a fair fee from the Fee Oracle.
  2. Fee Oracle replies with a fair fee.
  3. Node asks the Miner to include the transaction in a block.
  4. Miner confirms with the Fee Oracle that the fee is fair.
  5. Fee Oracle replies to the Miner that the fee is fair.
  6. Miner sends the block with a transaction to the Node.

Smart Contract

An Ethereum smart contract to submit a transaction.

submit

submit(nodeAddress, transaction, v, r, s)

An atomic submission of a transaction. The contract ensures that the transaction is valid and that the fee is fair. The parameters v, r, and s constitute the node signature.

Example: “I want to submit some transaction.”
submit(<nodeAddress>, <transactionData>, <v>, <r>, <s>)

Summary

The Swamp protocol serves a growing demand for a decentralized transaction sending on the Ethereum network. Pure blockchains, while novel and certainly within the ethos of the ecosystem, have limitations that we believe ultimately make it difficult for them to compete with currently available centralized solutions. Swamp provides a method that is both decentralized and unaffected by these limitations.

By implementing the protocol, participants gain access to the system in a scalable, private, and fair way, without sacrificing access to great pricing. The protocol and APIs are extensible and we encourage the community to build applications with us. We welcome feedback and look forward to pushing the Ethereum community forward with you.

For questions, comments, or feedback, please reach us at evge.medvedev@gmail.com.

--

--