Skip to content

sep-0022.md

Latest commit

 

History

History
135 lines (96 loc) · 4.81 KB

sep-0022.md

File metadata and controls

135 lines (96 loc) · 4.81 KB

Preamble

SEP: 0022
Title: IPFS Support
Author: Samuel B. Sendelbach <[email protected]>
Status: Draft
Created: 2018-11-11

Simple Summary

Adding IPFS support to Stellar increase functionality of the ecosystem with a smaller initial overhead than building a Stellar-specific large data store and peer-to-peer messenger.

Suggested additions:

  1. Add a multi-hash field in the transaction memo.
  2. Add an account operation for requesting communication between accounts.

Abstract

Currently Stellar does not support attaching large amounts of data to a transaction (in a decentralized manner), nor does it support decentralized peer-to-peer messaging at the account level. IPFS specializes in data storage and peer-to-peer networking. Formally supporting IPFS on Stellar would bolster Stellar's functionality with a minimal overhead compared to writing a stellar-specific data storage and messaging layer.

This proposal outlines two suggested additions to the Stellar-protocol. The first proposal is to add a multi-hash field in the transaction memo to accommodate referencing data stored on IPFS in a transaction. The second proposed feature is an account operation for requesting communication between two accounts. Although not IPFS specific, an INIT_COMM operation would immediately enable IPFS p2p messaging as well as many other communication protocols.

Motivation

"IPFS (the InterPlanetary File System) is a new hypermedia distribution protocol, addressed by content and identities. IPFS enables the creation of completely distributed applications. It aims to make the web faster, safer, and more open." -IPFS

"Using the Stellar network, you can build mobile wallets, banking tools, smart devices that pay for themselves, and just about anything else you can dream up involving payments! Even though Stellar is a complex distributed system, working with it doesn’t need to be complicated." -SDF

Both IPFS and Stellar are platforms that open the doors for decentralized applications. Combining a fast payment layer with a decentralized data layer would allow the Stellar ecosystem to venture into more complex decentralized applications. Namely machine to machine markets, coordinating multi-signature transactions, and "smarter" smart contracts.

Specification

1) multi-hash in the transaction memo.

An additional field in the transaction memo type explicitly for coupling IPFS hashes (data references) to transactions. The field should be capable of storing 64 bytes.

MEMO_TEXT : A string encoded using either ASCII or UTF-8, up to 28-bytes long.

MEMO_ID : A 64 bit unsigned integer.

MEMO_HASH : A 32 byte hash.

MEMO_RETURN : A 32 byte hash intended to be interpreted as the hash of the transaction the sender is refunding.

+++ `MEMO_IPFS` : A 64 byte hash intended to be interpreted as an IPFS multihash.

2) INIT_COMM operation.

INIT_COMM is proposed means of establish a direct link between two accounts. The INIT_COMM should act as an misc account effect. Services that wish to support direct communication would listen to a stream of their accounts effects and act on any INIT_COMM effects. To hide the communication address from the rest of the network, the address could be automatically signed with the public key of the recepient. IPFS supports peer-to-peer messaging via a multi-address routing. A multi-address supports multiple transportation protocols and IP4/IP6. This operation is not limited to IPFS alone. A standard address and protocol could be used like tcp://0.0.0.0:3000. This maximizes flexibility while immediately enabling peer-to-peer communication.

Rationale

1)

Why 64 bytes for the MEMO_IPFS? IPFS developer discussion here.

Why we need to add IPFS support: Stellar currently allows data to be referenced on ledger with transaction memos but the data is not cryptographically verifiable (unless using a custom method). Meanwhile, IPFS data references are innately verifiable due to the underlying merkle tree.

Stellar Dev Discussion: #32

2)

Although a generic messaging layer baked into stellar would be nice, it then limits the communication methods. On-chain communication carries a hefty overhead and may not scale-well. Discussion on messaging can be found here.

An independent communication operation does not lock the recepients into a specific protocol and can support extremely high-performance messaging like UDP rather than tcp.

Backwards Compatibility

Addition rather than subtraction. This proposal should be fully backwards compatible.

Test Cases

Implementation