Walnut/Persistent Secure Distributed Computing

Persistent Secure Distributed Computing
There is a problem with the programs we explored in the last chapter. The MarketPlace server, the RaceTrack server, and eChat are not persistent: once you shut them down they are gone forever. You can start up a new server with the same code, but it will not return to life with the same URI it had before. As a consequence, if you restart a server, you must redistribute the capability to access that server to all the users. This is a logistical nightmare. When we restart one of these servers, it must be able to restart with the same VatID and object IDs it had before.

If E simply allowed objects to remember their own URIs, there would be extensive opportunities for object forgery in the mobile code systems described in the next chapter. To prevent such forgeries, E uses swiss bases for persistence.

Swiss Bases
(XXX need to explain swiss numbers within Walnut, either here or earlier.)

(XXX should Walnut link to general wiki pages, or only within itself?)

To claim (to the comm system) that an object is that which should be referred to by an outside sturdyRef, the swiss base for that sturdyRef must be presented. The 'swiss base' is the number which hashes to the swiss number in the sturdyRef. Knowing the swiss base allows you to compute the swiss number, but knowing the swiss number does not allow you to compute the swiss base.

Every holder of a sturdyRef knows its swiss number. Only the party which controls what the sturdyRef refers to knows its swiss base.

If you use  to manage your persistent program, as the example below does, then   manages the swiss bases for you.

Example: Persistent eChat
(XXX write explanatory text, and review this code w.r.t. what concepts Walnut has and hasn't introduced. Was copied from persist-echat.e-awt in the distribution.)

Next Section: Secure Mobile Code