doc/dogecode-whitepaper.markdown

   1 Dogecode White Paper v0.1
   2 =========================
   3
   4 __Rob Myers <rob@robmyers.org>__
   5
   6 __23-12-2014__
   7
   8 Overview
   9 ========
  10
  11 Dogecode (name to be finalized) is a system for representing computer programs using sequences of Dogeparty tokens in order to store, send, and execute their code via the Dogecoin blockchain.
  12
  13 Tokens
  14 ======
  15
  16 The encoding for programs is a minor variant of the "Brainfuck" programming language, chosen for its minimalism:
  17
  18 [http://en.wikipedia.org/wiki/Brainfuck](http://en.wikipedia.org/wiki/Brainfuck)
  19
  20 Each Brainfuck programming language command is represented by an indivisible Dogeparty asset.
  21
  22 A single occurrence of a command in a program is represented by the sending of a single token, e.g. + is represented by sending 1 INCB tokens .
  23
  24 Multiple occurrences are represented by sending multiple tokens in a single transfer, e.g. +++++ is represented by sending 5 INCB tokens.
  25
  26 The order and quantities of sends are significant, not the total number of tokens held by an address or account.
  27
  28 Currently Used Tokens
  29 ---------------------
  30
  31 Reading bytes into the pointer (the "," command in Brainfuck) isn't currently supported. To enter data, use "+" and ">".
  32
  33 INCP - > (Increment pointer)
  34
  35 DECP - < (Decrement pointer)
  36
  37 INCB - + (Increment byte at pointer)
  38
  39 DECB - - (Decrement byte at pointer)
  40
  41 PUTB - . (Write byte at pointer)
  42
  43 JFOR - [ (Jump forward if byte at pointer is not zero)
  44
  45 JBAK - ] (Jump back if byte at pointer is not zero)
  46
  47 Reserved Tokens
  48 ---------------
  49
  50 These tokens are reserved to support future functionality.
  51
  52 GETB - , (Read byte into pointer)
  53
  54 IDAT -   (Identify data to be read by READ. See Input/Output below.)
  55
  56 RUNC -   (This section of the code is complete, run it.)
  57
  58 BADC -   (This section of the code has a problem, do not run.)
  59
  60 Encoding Of Programs
  61 ====================
  62
  63 Programs are represented as a sequence of quantities of Dogecode tokens sent from a single address. Order, quantity and sending address are all significant to the system.
  64
  65 Ideally, programs would be represented as multiple sends in a single transaction. Until this is implemented, programs must be sent as an uninterrupted sequence of Dogecode tokens from a single address (no other tokens from the same address may interrupt the send).
  66
  67 Single Program Addresses
  68 ------------------------
  69
  70 Single program addresses represent programs as a newly created Dogeparty address holding only the tokens sent to it in sequence that represent that single program's code.
  71
  72 No additional programs may be stored using that address.
  73
  74 If transferring the tokens fails or the program is found to be incorrect before it runs, a new address must be created and the correct sequence of tokens sent to it.
  75
  76 Program Queue Addresses (Not Yet Implemented)
  77 ---------------------------------------------
  78
  79 Programs queued on an address for exection consist of a sequence of quantities of Dogecode tokens sent from a single address.
  80
  81 Since programs cannot be sent as multiple tokens in a single transaction two addresses may send programs at (approximately) the same time, leading to program token sends from two or more addresses becoming interleaved. This requires sorting token sends by address as well as by time when fetching programs to run.
  82
  83 Input/Output
  84 ============
  85
  86 Input Via +/>
  87 -------------
  88
  89 Data can be entered into memory using the + and > commands. This is currently the only supported method for entering data into a program.
  90
  91 Input Via IDAT Token (Not Yet Implemented)
  92 ------------------------------------------
  93
  94 Details forthcoming.
  95
  96 Output For Single Program Addresses
  97 -----------------------------------
  98
  99 Output is determined by running the program locally.
 100
 101 Output For Program Queue Address Runner (Not Yet Implemented)
 102 -------------------------------------------------------------
 103
 104 Output is provided via broadcast messages on the Program Queue Address (details forthcoming).
 105
 106 Running Programs
 107 ================
 108
 109 Single Program Addresses
 110 ------------------------
 111
 112 To execute the program, the system fetches all sends to the address in order and converts their token amounts to runs of Brainfuck commands. It then passes the resulting string to a Brainfuck interpreter. This will provide the final state and output of the program.
 113
 114 Program Queue Address (Not Yet Implemented)
 115 -------------------------------------------
 116
 117 Programs can be sent to an address that you control in order to be run in a queue.
 118
 119 Transactions from other addresses are ignored.
 120
 121 Used tokens can be returned to the sending address or, if the queue address is also the sending address, kept for re-use.
 122
 123 The runner polls the send table for new sends to the queue address. Sequences of tokens sent from a single address constitute programs to be executed. Programs are terminated with a RUNN token to trigger their execution, or an ERRR token if they should not be executed because (e.g.) a bug was found or the upload was corrupted.
 124
 125 The output of the program can either be recorded locally or output via broadcast messages from the runner address (details forthcoming).
 126
 127 To prevent programs that do not complete in a reasonable amount of time from disrupting the operation of the queue, programs should be run on a thread with a short timeout (details forthcoming).
 128
 129 Program Queue Address As A Service (Not Yet Implemented)
 130 --------------------------------------------------------
 131
 132 For Dogecode as a service, a program queue address that you control can execute Dogecode programs sent from addresses that others control in return for payment.
 133
 134 Tokens sent to the runner address are not returned, they constitute part of the payment for the service. Additional payment is sent as a Dogecoin transaction following the program tokens.
 135
 136 This system does not use RUNN/ERRR tokens to control execution. Receiving the Dogecoin payment acts as the command to execute the program. Should the payment not be sent within two minutes the program is not run and the tokens are forfeit - unsuccessful or erronious program uploads can have their execution cancelled by not sending payment. Should the incorrect amount of payment be sent, it can be corrected by sending a supplementary payment before any further Dogecode tokens are sent. If a supplement is not sent within two minutes, the tokens and incorrect payment are forfeited to the runner account.
 137
 138 The output of the program is output via broadcast messages from the runner address (details forthcoming).
 139
 140 To prevent programs that do not complete in a reasonable amount of time from disrupting the operation of the queue, programs should be run on a thread with a short timeout. The length of the timeout can be extended by the sender incorporating an additional supplement into the Dogecoin fee that triggers execution (details forthcoming).
 141
 142 Dogecoin prices for running are announced by the runner account on its broadcast message feed (details forthcoming).
 143
 144 Token Transfer Speed
 145 ====================
 146
 147 Dogecode programs must be sent as ordered sequences of individual Dogeparty asset "send" commands. To ensure that the token sends are incorporated into the blockchain in order, each send is performed only after the previous one is confirmed. This means that it can take minutes for each token run to be sent to the receiving account.
 148
 149 Multiple sends from the same account in the same block could be enabled by having multiple inputs available to it, this does not ensure ordering however.
 150
 151 Ideally, Dogeparty would be extended to allow multi-token sends in a single Dogecoin transaction. This would solve both confirmation and ordering.