/ smart-contracts / donut-lab

Dough Notes

first race condition in several years of E programming

virtual os slivers are unsafe to put behind a firewall: though the underlying machine may be safe from direct attack from within the protection boundary formed by the virtual OS, the sliver, with its full TCP/IP addressing authority, can read and write file volumes that have been shared behind the firewall, can sniff ethernet packets, can send email with viruses attached to people inside the firewall that would have been stripped out by the firewall, and can read company sensitive internal web pages that are also supposed to be protected from outsiders by the firewall.

None of these problems exist with the donut sliver. It does not have full TCP/IP authority: it has specifically the authority to communicate with any other object for which it is given a live ref ....

Compare this on the other hand to java applets, which might at first glance seem to have the same security properties. Java applets by default have the authority to speak to the site that launched them; in donutlab this would be equivalent to being able to talk to the domain where the sliceboss resides. However, the sliceboss cannot confer authority to talk to objects on other sites to the applet: there is no concept of dynamic allocation of authority. Hence the only way applets could work in a planetlab or donutlab is by routing all messages through the site that created the applet, a strategy that effectively renders the applet useless for planetlab-like applications

All comparisons made to PlanetLab in this paper are comparisons to PlanetLab as it existed at the beginning of the DonutLab 48 hour effort. It does not make comparisons to hypothetical enhancements of PlanetLab which could be deployed after unknown amounts of effort.

obvious enhancements: moneychanger, ratings services, multi-protocol access to specified domains, support for apps with multiple libraries (files).

introduction supergoal: Numerous efforts have been startedin recent years to build programming languages capable of compactly and reliably representing large secure distributed systems (E, OzE, JoeE, SqueakE, etc). These efforts are, from different directions and with different speeds, moving toward a view of distributed systems that supports persistent distributed object capabilities for security with promise pipelining for network traffic handling, to maximize robustness and effective use of bandwidth while minimizing the impact of latency, which seems the long term, intractable bottleneck in distributed systems.

Workers in the field of distributed object capabilities tend to look at PlanetLab and feel a sense of chagrin, knowing that a PlanetLab built in a more powerful paradigm could be easier to use, more secure, easier to maintain, more scalable, and more robust, all at the same time. PlanetLab members reasonably pointed out that if this is the case, then some one thing must be easier and better that could be built as a demonstration.

Our supergoal, then, was to demonstrate the advantages of using secure distributed programming tools for the building of secure distributed systems like PlanetLab. However, a good demonstration vehicle proved difficult to identify, for the following reason: while the entire world may be easier if done uniformly inside a new paradigm, it can be quite traumatic and expensive to build a small element of a new paradigm that is supposed to strap onto the side of an existing legacy system that is, unintentionally effectively, quite hostile to new paradigms. It can be far more expensive to create the bridge between paradigms than to build any individual module. Indeed, it can be much less expensive to build an entire system in the new paradigm than to build the bridge to a small piece.

Therefore, the concept of DonutLab was conceived as a complete rebuild from scratch of a PlanetLab-like system that embodies the new paradigm. DonutLab is intended to have all the positive characteristics of PlanetLab plus all the additional positive characteristics that asuperior paradigm can deliver. While the 48 hour DonutLab does not achieve this full goal, it points the way clearly; straightforward enhancements listed at the end of this paper would indeed encompass all the power of PlanetLab with none of its liabilities.

----

BigBang for individual service, the first creation of a service. persisting the first kiosk: circular creation problem, introducer must be made first so that account can be loaded from file to be used to create the kiosk, but introducer must be last so persistence system can be initiated after the kiosk is initiated. Solved with promises: a promise for an account is created, the promise is resolved after the introducer is created after the kiosk is created.

---

bigBang for the system as a whole: first create mints, which are dependent on no one else. Then kiosks, dependent only on mints. Then sliver servers which need both. Then apps. Adding multiple mints, which means adding multiple mints, increases the complexity significantly: moneychangers need to come to life with accounts on multiple mints, which must be hardwired.

----

Another 72 hours. based on what we have learned, we believe we could add the following features in another 72 hours: moneyChangers, though these can spontaneously evolve as third parties add new mints, and new services that use these mints

------

upgrades of persistent systems: done routinely in the last day of the effort, as we modified the code for the sliverserver and brought the sliverserver back to life with the new code.

----

encountered true concurrency race condition bug in 3-vat comm, which is interesting considering how rare such bugs have appeared in the 2 previous years when much use of 2-vat comm was done

----

iou mint holds cannot subdelegate expenditures. The doughbot needs to receive the whole account, it cannot simply be given a hold with the amount of money it is authorized to spend on an attack (this amount must in turn be subdivided, part of it being sent out for each sliver rented).

---

for beginning users of donutlab, the transfer op in the mint should do a vowTransfer, not demand it of all users.

---

lop off the head of the doughbot, it does not stop the attack. you have to stop all the doughbits on all the sliverservers.

----

demo version of the doughbot is the slowbot. show slow code, full pipelining code, compare contrast.

----

The "just do it" philosophy encouraged by promise pipelining: don't check to see if something will work before composing a bunch of stuff to do it, this is both unreliable, unnecessary, and inefficient because of latency. Just do it. example, sending money to all the sliverservers you got from a kiosk even though some might be down. If they are down, the money refunds, if they are up, it just works with no round trip. If they are up when you check, but then go down while you are now gearing up to use it, it was unreliable and you have to handle this exceptional case anyway.

----

use of promises to make "big bang" easier"

----

ease of moving authorities around by simply moving files around: making the doughbot share an account with the sliverserver for testing purposes.

----

things to fix for demo:
show credit counting down on the sliverserver
reformat hits/misses line, use term "salvo"
cleanup traces from kiosks
rename "test area" "target"
multiple sliverservers

------

things to fix for robustness for another programmer/experimenter:
kiosks detect loss of liveref, delist the server
kiosks and sliverservers set timers, refresh their ads regularly
unlimited persistent account construction
grabCash on donutAccount
kiosks and sliverservers detect loss of connection to mint, poll for mint return (need sturdyrefs, not liverefs). For demoing, doughbits should do this too.

------

things to fix for full-up example:
second mint
moneychangers. Minimal is transient exchanges, better is to build a bank where you can make a deposit, this is robust if mint1 is down and you still want to work using mint 2.

-----

to understand the donutlab, you need to understand not only software and capabilities and promises, you also need to understand financial systems, how they operate.