Skip to content

Latest commit

 

History

History
58 lines (43 loc) · 3.36 KB

PIP-0016.md

File metadata and controls

58 lines (43 loc) · 3.36 KB
Raw
  PIP: PIP-0016
  Title: Layer-2 protocol support
  Type: Protocol
  Impact: Hard-Fork
  Author: Herman Schoenfeld <herman@sphere10.com>
  Comments-URI: https://discord.gg/sJqcgtD  (channel #pip-0016)
  Status: Proposed
  Created: 2018-01-04

Summary

A new operation DATA is propose to facilitate data exchange between accounts. This will allow clean enveloping of Layer-2 protocols inside Layer-1 much in the same way HTTP lives inside TCP.

Motivation

Currently, PascalCoin can facilitate Layer-2 protocols by allowing them to be enveloped within the Layer-1 Transaction operations. This is achieved by using the Payload field inside operations. Whilst this is useful, it has some drawbacks such as requiring double the fee and hard to distinguish between payments and data exchange. Whilst it's possible to send BLOB data over many 256 bytes payloads, it's hard for receiver to sequence these operations since some may payloads may be PASC others part of Layer-2 protocol. As a result, a new operation is required to cleanly support Layer-2 protocol eveloping. As a result, Layer-2 applications can quickly aggregate messages without needing to inspect every payload of every message and ordinary nodes can discard these Data messages after 100 blocks without any further burden.

Specification

A new operation called DATA is proposed that allows accounts to send data to another account.

New Operation: DATA

  • ID: 16 bytes - this is a GUID created by the sender
  • Type: Word - this is used by Layer-2 protocol to distinguish different types of messages (i.e. 0 - CHAT MESSAGE, 1 - PRIVATE MESSAGE, 2 - FILE, etc)
  • Sequence: this is used by Layer-2 protocol to envelope it's message into many Layer-1 messages, just as HTTP response is enveloped over many TCP messages.
  • Account: this is the account authoring the operation
  • Destination: this is the account receiving the operation
  • Quantity: this is an optional PASC quantity to transfer (can be 0)
  • Fee: the network fee payable to miner
  • Payload: the 256 byte operation payload containing Layer-2 data
  • Signer: this is the signer account which pays the fee
  • Signature: ECDSA signature of entire operation

Consensus Rules

  • The Signer Account balance must greater than or equal to Fee
  • The public keys for Signer Account and Account must be identical
  • The Signature must be well-formed ECDSA signature verifiable using Signer Account's public key
  • Account balance >= Quantity + Fee

Mutation Rules

  • Account Balance = Account Balance - Quantity
  • Signer Balance = Signer Balance - Fee
  • Account NOperation = Account NOperation + 1
  • Destination Balance = Destination Balance + Quantity

NOTE It's important to note that this operation only transfers data between accounts, not PASC or PASA. Since nodes delete these operations after 100 blocks, it's up to Layer-2 applications to ensure they are persisted separately.

Rationale

As mentioned in Motivation section, enveloping layer-2 protocols inside layer-1 can be achieved without this operation however it introduces many unncessary complexities. Also, by segregating DATA operations from PASC transactions, nodes can quickly filter Layer-2 protocols without expensive introspection of every Transaction.

Backwards Compatibility

This change is not backwards compatible and requires a hard-fork activation.