Long Running Transactions

We once faced the challenge of automating many of our manual workflows while minimizing the cost of doing so. Having seen similar efforts fail, we chose a new design point that we believed would entice more of our stakeholders to participate. eclipse

We now consider how what we once learned might suggest strategy for smart contracts distributed in the context of federated wiki.

# Explain

Our solution has been to script and visualize long running transactions by simulating them using test databases and capturing the output for display.

The simulation uses as much of the real application code as possible, replacing only the real databases with test databases, the user input routines with the test scripts, and the browser output with output stored in buffers for post-processing and evaluation. Consequently the simulated transactions are the real transactions and the scripts are testing the real application code and business logic.

# Perform

Because our transactions can take weeks or months to complete, we obviously run our simulations faster than real time using a simulated clock. In production a centralized database tracked the progress, emitted messages prescribed by the workflow, and then reached one conclusion or another when completed.

We have demonstrated how digital signatures can confirm agreement of stakeholders. We imagine a "plan" can describe both the stakeholders and the progression of further agreements that constitute following the plan. An outline for a plan might start from a familiar template and then be customized until launched by the initial agreement.

We would expect a plan to be expressed with some precision such that all paths through the plan can be enumerated and all outcomes recognized before the first agreement of stakeholders. example

Similarly, any stakeholder should know plainly what further agreements are required before a specific outcome is universally recognized and accepted. The Eclipse "Swim" System suggests what one could expect to be "plainly known".

If messaging is confined to those who have signed pages then we can replace the email reader with a wiki page that summarizes all obligations that are still active within the site used for signing. A Site Survey could probe for contracts needing action and present that just like an email reader.

# Examples

Robert and Ward Agree to harden the Signature plugin.