Semi-Automated Transactions Introduction Automated transactions is the

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
# Semi-Automated Transactions
## Introduction
Automated transactions is the hot topic in NXT community today. Unfortunately, there are many concerns around current proposals: processing power / memory usage (and halting problem prevents from analysing those issues in prior [1]), possible issuing of unsigned transactions, cancellation problem(what if a script have received money and going to exhaust because of all money spent)? All the problems could be divided into 3 categories:
1. Halting problem and its consequences in case of Turing-Complete systems analysis.
2. Blockchain-related problems. Blockchain is versioned database, and an event could occurs only when block comes. How can arbitrary script handle this?
3. Consensus problems. To save resources current approaches propose to execute scripts on just some nodes and issue unsigned transactions as a result . So instead of "51% stake" consensus we immediately get "51% of a script executing nodes" consensus which is way too much weak.
To solve all of those problems I suggest to implement much safer approach having no all 3 kinds of problems:
1. Instead of Turing-Complete arbitrary scripting we should simple pattern-matching over finite space of states(Finite State Machines).
2. As reactive systems seems to be the best approach to interact with blockchain events, Finite State Machines solves step-by-step blockchain nature handling problem for free.
3. We should use no unsigned transactions / nodes grouping and other suspicious concepts. Instead, account will issue transactions automatically in "forging" or "scripting" mode. As a security measure, an account have to leave a deposit before script will get into finish state. So a currency infrastructure couldn't force an account to pay, but an account can't spend some amount of money stated in prior.
## Description
A script is being written in high-level declarative language based on pattern-matching[3] and explicitly given states. There are two mandatory states: init and finish.
Pattern matching clause specifies current state conditions over current system state & incoming transactions, and actions to do if conditions match, and state to transit to as well. Naive description introduced in [2]. I go to describe things around in detail. Let's consider simple example:
```
deposit=0 nxt
Init: tx:transaction(amount>1 nxt, sender=="NXT-PKXM-WH25-UXXG-11111") => deposit+=tx.amount :S1
S1: stayingInStateForMoreThan(20 blocks) => sendMoney(tx.amount, recipient="NXT-PKXM-WH25-UXXG-11111") :Finish
S1: transaction(type="message", text<=="agree", sender=="NXT-PKXM-WH25-UXXG-11111") => sendMoney(tx.amount - 2 nxt, recipient="NXT-PKXM-WH25-UXXG-22222") :Finish
Finish: =>
```
The script means "on incoming transaction from NXT-PKXM-WH25-UXXG-11111 having amount of more than 2 NXTs, goto state S1, on incoming message in that state from same account containing word "agree" send money received without 2 NXTs to account NXT-PKXM-WH25-UXXG-22222.". Deposit will be described later.
### Publishing / Running/ Stopping Script
An account willing to run script publishes it into blockchain via RUN_SCRIPT kind of plain message containing script text. There is another STOP_SCRIPT command which could be valid only if script is in finish state(or should waits for final state?)
### Execution & Deposit & Consensus
As in all other features existing in NXT, all scripts are executes against all nodes. A node save current script's state & deposit size in its internal state and checks whether script account makes actions to transit into another state. Also it checks on any transaction remaining balance(I think of effective balance, having > 1440 confirmations) is not less than deposit.
### Hanging
As in some cases()
## Implementation
### Phase 1
### Phase 2
## Open problems
* Random number generation - a random number function result has to be same for all nodes, but random with an arbitrary distribution.
## References
1. What is static program analysis? by Matt Might http://matt.might.net/articles/intro-static-analysis/
2. ATs with FSM-based DSL https://nxtforum.org/automated-transactions/ats-with-fsm-based-dsl/
3. Pattern Matching. http://en.wikipedia.org/wiki/Pattern_matching