|
@@ -0,0 +1,143 @@
|
|
|
|
+<pre>
|
|
|
|
+ PIP: PIP-0028
|
|
|
|
+ Title: E-OP: Layer-2 operation encoding standard for smart-contracts
|
|
|
|
+ Type: Frontend
|
|
|
|
+ Impact: None
|
|
|
|
+ Author: Herman Schoenfeld <[email protected]>
|
|
|
|
+ Comments-URI: https://discord.gg/sJqcgtD (channel #pip-0028)
|
|
|
|
+ Status: Proposed
|
|
|
|
+ Created: 2019-03-05
|
|
|
|
+</pre>
|
|
|
|
+
|
|
|
|
+## Summary
|
|
|
|
+
|
|
|
|
+This PIP proposes an operation encoding scheme to simplify integration into Layer-1 by Layer-2 Smart Contracts and also 3rd party infrastructure such as exchanges and wallet providers.
|
|
|
|
+
|
|
|
|
+## Motivation
|
|
|
|
+
|
|
|
|
+PascalCoin currently allows external software to send/receive operations via a JSON API. This requires the 3rd party systems conenct to a live trusted node and interact programmatically.
|
|
|
|
+
|
|
|
|
+This can be undesirable since 3rd parties may which to provide separation between their systems and node as well require ability for offline operation creation (cold-signing). Layer-2 smart-contracts also need a concise and simple method to submit Layer-1 operations between nodes.
|
|
|
|
+
|
|
|
|
+In combination with [E-PASA][1], this PIP allows external software to trivially integrate into PascalCoin by sending single E-OP's to either a JSON API or a In folder which is picked up by the node.
|
|
|
|
+
|
|
|
|
+This proposal will greatly simplify exchange and wallet integrations as well as allow Layer-2 applications to submit Layer-1 operations with great ease.
|
|
|
|
+
|
|
|
|
+## Specification
|
|
|
|
+
|
|
|
|
+E-OPs are simplified encodings of PascalCoin operations in the same manner as (E-PASA)[1].
|
|
|
|
+
|
|
|
|
+### Operation Structure
|
|
|
|
+
|
|
|
|
+PascalCoin Operations are currently structured as follows:
|
|
|
|
+
|
|
|
|
+### Extended Operation (E-OP) Format
|
|
|
|
+
|
|
|
|
+An Extended Operation is defined by the below EBNF grammar:
|
|
|
|
+
|
|
|
|
+```
|
|
|
|
+ EOP = ( Transaction | ChangeKey | Info | Recover | List | Delist | Buy | Data | MultiOp );
|
|
|
|
+ Transaction = "TXN:", PASA, ":", [NOp, ":"], EPASA, ":", PASC, ":", [BuyKeyData, ":"], [Fee, ":"], [Signature]
|
|
|
|
+ ChangeKey = "KEY:", EPASA, ":", PASA, ":", [NOp, ":"], [Fee], Key, ":", [Signature]
|
|
|
|
+ Info = "ACCINFO:", EPASA, ":", PASA, ":", [NOp, ":"], [Key, ":"], [Name], ":", [Integer, ":"], [Fee, ":"], [Signature]
|
|
|
|
+ Recover = "RECOVER:", PASA, ":", [NOp, ":"], [Fee]
|
|
|
|
+ List = "ENLIST:", EPASA, ":", PASA, ":", [NOp, ":"], PASC, PASA, Key, [Signature]
|
|
|
|
+ Delist = "DELIST:", EPASA,":", PASA, ":", [NOp, ":"], [Signature]
|
|
|
|
+ Buy = "BUY:", PASA, ":", [NOp, ":"], ":", EPASA, ":", PASC, ":", BuyKeyData, ":", [Fee, ":"], ":", [Signature]
|
|
|
|
+ Data = "DATA:",PASA, ":", [NOp], ":" PASA, ":", EPASA, ":", Integer, ":", Integer, ":", PASC, ":", [Fee, ":"], [Signature]
|
|
|
|
+ MultiOp = "MULTI:", "SEND[", {MultiOp_Sender}, "]:", "RECEIVE[", {MutiOp_Receiver}, "]:", "CHANGE[", {MultiOp_Changer}, "]"
|
|
|
|
+ MultiOp_Sender = EPASA, [NOp], PASC, [Signature]
|
|
|
|
+ MultiOp_Receiver = EPASA, PASC
|
|
|
|
+ MultiOp_Changer = EPASA, Integer, ":", [Key, ":"], [Name, ":"], [Integer,":"], [Signature]
|
|
|
|
+ PASC = Integer [".", [Digit, Digit, Digit, Digit]]
|
|
|
|
+ BuyKeyData = PASC, ":", PASA, ":", Key, ":", Key ":"
|
|
|
|
+ Fee = "F", PASC
|
|
|
|
+ NOp = "N", Integer
|
|
|
|
+ Key = "K", Base58String
|
|
|
|
+ Signature = "SIG:", Base58String
|
|
|
|
+ Name = "L": Pascal64String
|
|
|
|
+ other = See PIP-0027 for these grammar for definitions
|
|
|
|
+```
|
|
|
|
+
|
|
|
|
+The above grammar is parsed into the below logical structures:
|
|
|
|
+
|
|
|
|
+PIP-0027 grammars referenced above can be found [here](https://github.com/PascalCoin/PascalCoin/blob/master/PIP/PIP-0027.md#extended-pasa-format-e-pasa).
|
|
|
|
+
|
|
|
|
+```
|
|
|
|
+ Transaction = Sender PASA, [Sender NOperation], Destination EPASA, Amount, [BuyKeyData], [Fee], [Signature]
|
|
|
|
+ ChangeKey = Target EPASA, Signer PASA, [Signer NOperation], [Fee], Key, [Signature]
|
|
|
|
+ Info = Target EPASA, Signer PASA, [Signer NOperation], [PublicKey], [Name], [Type], [Fee], [Signature]
|
|
|
|
+ Recover = Expired PASA, [Expired NOperation], [Fee]
|
|
|
|
+ List = Target EPASA, Signer PASA, [Signer NOperation], Target Price, Seller PASA, Key, [Signature]
|
|
|
|
+ Delist = Target EPASA, Signer PASA, [Signer NOperation], [Signature]
|
|
|
|
+ Buy = Sender PASA, [Sender NOperation], Destination EPASA, Amount, BuyKeyData, [Fee], [Signature]
|
|
|
|
+ Data = Signer PASA, [Signer NOperation], Sender PASA, Destination EPASA, Type, Sequence, Amount, [Fee], [Signature]
|
|
|
|
+ MultiOp = {MultiOp_Sender}, {MutiOp_Receiver}, {MultiOp_Changer}
|
|
|
|
+ MultiOp_Sender = Account EPASA, [N Operation], Amount, [Signature]
|
|
|
|
+ MultiOp_Receiver = Account EPASA, Amount
|
|
|
|
+ MultiOp_Changer = Acount EPASA, ChangeFlag, Key, Name, Type, [Signature]
|
|
|
|
+ BuyKeyData = AccountPrice, SellerAccount, Current Key, New Key,
|
|
|
|
+ Key = CurveID, X-COORDINATE, Y-COORDINATE
|
|
|
|
+ Signature = R-COORDINDATE, S-COORDINATE
|
|
|
|
+
|
|
|
|
+```
|
|
|
|
+
|
|
|
|
+## E-OP Examples
|
|
|
|
+
|
|
|
|
+### Data Operations
|
|
|
|
+
|
|
|
|
+```
|
|
|
|
+ DATA:277-44:277-44:77-44(0x416c70686124):10cb:1:0:0.0000:F0.0001
|
|
|
|
+```
|
|
|
|
+
|
|
|
|
+Layer-2 application constructs above string which denotes:
|
|
|
|
+- A data operation from 277-44 to 77-44, signed by 277-44
|
|
|
|
+- Includes a hexadecimal payload 0x416c70686124 ECIES encrypted using senders key and checksum protected
|
|
|
|
+- The data operaton type is 1 and sequence is 0
|
|
|
|
+- Transfers 0.0000 PASC and pays fee of 0.0001 PASC
|
|
|
|
+
|
|
|
|
+```
|
|
|
|
+ DATA:277-44:123:277-44:77-44(0x416c70686124):10cb:1:0:0.0000:F0.0001:SIG:BvBMSn5AEYstWetqT1Fu4m4GFgstWet7xJaNVN21BvstWestWetqTFn5Au4m4GFg7xJaNVN2
|
|
|
|
+```
|
|
|
|
+- Same as above but signed by Layer-2 application
|
|
|
|
+- Notice inclusion of senders n-operation (123) and the signature
|
|
|
|
+
|
|
|
|
+
|
|
|
|
+### Transactions
|
|
|
|
+
|
|
|
|
+```
|
|
|
|
+ TXN:277-44:123456-77["Hello World!"]:10cb:100.0000:F0.0001
|
|
|
|
+```
|
|
|
|
+
|
|
|
|
+Layer-2 application constructs above string which denotes:
|
|
|
|
+- A transaction from 277-44 to 123456-77
|
|
|
|
+- For 100 PASC paying fee 0.0001 PASC
|
|
|
|
+- No sender n-operation is specified (layer-1 needs to look up)
|
|
|
|
+- Includes a public payload "Hello World!" with checksum protection
|
|
|
|
+- The operation is to be signed by layer-1 node (must have key for 277-44)
|
|
|
|
+
|
|
|
|
+
|
|
|
|
+```
|
|
|
|
+ TXN:277-44:123:123456-77["Hello World!"]:10cb:100.0000:F0.0001:SIG:BvBMSn5AEYstWetqT1Fu4m4GFgstWet7xJaNVN21BvstWestWetqTFn5Au4m4GFg7xJaNVN2
|
|
|
|
+```
|
|
|
|
+
|
|
|
|
+- Same as above but cold-signed by the Layer-2 application
|
|
|
|
+- Notice inclusion of senders n-operation (123) and the signature
|
|
|
|
+
|
|
|
|
+
|
|
|
|
+## Rationale
|
|
|
|
+
|
|
|
|
+The design approach was to allow Layer-2 to easily integrate into Layer-1 and to make operation declarations more concise and unambiguous.
|
|
|
|
+
|
|
|
|
+The use of JSON was also possible, and perhaps desirable due to easier implementation, however the operations would not be concise one-liners.
|
|
|
|
+
|
|
|
|
+## Backwards Compatibility
|
|
|
|
+
|
|
|
|
+This PIP is backwards compatible and does not require a hard-fork activation, only an implementation change.
|
|
|
|
+
|
|
|
|
+## Reference Implementation
|
|
|
|
+
|
|
|
|
+WIP
|
|
|
|
+
|
|
|
|
+
|
|
|
|
+[1]: https://github.com/PascalCoin/PascalCoin/blob/master/PIP/PIP-0027.md
|