E-PASA

Summary

A backwards compatible addressing scheme that enables an infinite address-space within account-based blockchains that use ordinal account numbers (such as PascalCoin). The usage of these extension addresses can transform a bounded finite address space into an unbounded infinite address space.

Motivation

PascalCoin currently allows users to send/receive operations between accounts using their account numbers (PASA). These account numbers are a limited (and commoditized) resource which form a finite address-space (note: this is fundamental to SafeBox design and it's infinite-scaling capability).

PascalCoin will provide an infinite address-space (similar to other other crypto-currencies) via "decentralized custodial accounts" which are Layer-2 dApps governed via a Layer-2 Proof-of-Stake overlay network. Before rolling out this Layer-2 infrastructure, PascalCoin first needs to establish an addressing-scheme for this infinite address-space.

This PIP provides one such scheme. Additionally, this scheme can also be immediately employed at the presentation-layer to greatly simplify exchange integrations and payload-based payments.

Specification

Layer-2 addresses will be herein referred to as Extended PASA, or E-PASA for short.

An E-PASA has the following unique characteristics:

• Each E-PASA is a unique identifier.
• An E-PASA is encoded into the raw network payload of operations.
• There is a 1-1 mapping between E-PASA and their raw payload form.
  • They are deterministically dehydrated to into raw payloads.
  • They are deterministically hydrated from raw payloads ( note: requires V5 protocol).
• No two fully check-summed E-PASA's can refer to the same logical address.

Extended PASA format (E-PASA)

An Extended PASA is defined by the below EBNF grammar:

epasa = pasa, [ extendedAddress ], [ ':', extendedChecksum ] ;  
    pasa = ( accountName | accountNumber ) ;  
    accountName = pascal64String ;  
    accountNumber = integer, "-", checksum ;  
    checksum = digit, digit ;  
    extendedChecksum = hexByte, hexByte ;  
    extendedAddress = ( publicPayload | receiverEncPayload | senderEncPayload | passwordEncPayload ) ;  
    publicPayload = "[", [ payload ], "]" ;  
    receiverEncPayload = "(``, [ payload ], ")" ;  
    senderEncPayload = "<", [ payload ], ">" ;  
    passwordEncPayload = "{", [ payload ], ":", [ password ], "}" ;  
    payload = ( """, pascalAsciiString, """ | "0", "x", hexString | base58String ) ;  
    password = pascalAsciiString  
    ...  

Validation Rules

AccountNumber Checksum

Layer-1 account checksum must be the following number:

checksum = ((accountNumber * 101) MOD 89) + 10

Pascal64String

These strings are used to denote account names and conform to the following rules:

1. By definition, they must not start with a digit.

E-PASA Examples

Base Cases

With ASCII payloads

With Hexadecimal payloads

With Base58 payloads

Rationale

The design approach was to remain backwards compatible so that EPASA can replace "account" in existing JSON APIs. The caller need not specify Payloads anymore since the EPASA can contain the Payload.

Backwards Compatibility

This PIP is generally backwards compatible and does not require a hard-fork activation for using E-PASA as a convention.

For Layer-2 applications the ability for a receiver to auto-decode the E-PASA via PayloadType does require a hard-fork except although this does not prevent usage of E-PASA for other purposes.

Acknowledgements

• Ugochukwu Mmaduekwe for assistance developing payload length validation rules
• Benjamin Ansbach for regular feedback, assistance and insightful suggestions
• UrbanCohort for elegancy-improving suggestion

Reference Implementation

The following regex parses an E-PASA:

# Example of regex parsing implementation 

Full source-code for the above is available here.

A recursive-descent implementation can be found here.