See the History page for related prior work organized by how it led to E.
Related to Agoric Computing & Smart Contracts
Before we'd ever heard of Norm Hardy's KeyKOS or Nick Szabo's Smart Contracts, Eric Drexler & I collaborated on an earlier vision of capability-based market-oriented computing we call Agoric Open Systems.
Agorics, Inc., was originally founded to pursue this vision, as combined with insights from Norm's KeyKOS, Hewitt's Actors and Ehud Shapiro's Concurrent Logic Programming. These insights were brilliantly synthesized together by Dean Tribble into the Joule language. E's debt to Joule cannot be overstated.
Cohera is the latest venture of Michael Stonebreaker, creator of Ingres and Postgres. Cohera is commercializing Stonebreaker's Mariposa -- a massively scalable agoric distributed database. Cohera uses price information to distribute data and queries is ways that dynamically adapt to changing conditions.
Communities.com ("Electric Communities" at the time) was originally founded to pursue a somewhat similar and somewhat derived vision, in combination with grand Hayekian plans for a fully decentralized graphically-based secure system of social virtual realities. Communities.com developed E to support this vision. Communities.com successfully deployed an impressive beta, built securely on E, before the company changed direction. Fortunately, Communities.com had the wisdom to open-source E at that time, so work on it could continue independently.
Marc Stiegler's latest science fiction book, EarthWeb, opens with a scene depicting a cryptographic-capability-based exchange of electronic rights, mediated by an intermediary following the logic of E's Escrow Exchange Agent.
See Mozart below.
Related to Capabilities
Inspired by KeyKOS, Jonathan Shapiro has built and open sourced! EROS, a KeyKOS-like pure capability operating system. EROS seems to have all the virtues of KeyKOS, better performance, a high quality port to the x86 architecture, and the first formal proof of various important security properties. And most important, EROS is free of the intellectual property entanglements that plague KeyKOS. Check it out!
The Foresight Institute at one time made a valiant start on bringing together material for a web-based debate on Capabilities vs other security paradigms (especially ACLs). If there is enough interest, it would be wonderful to see this effort revived.
Jonathan Rees's thesis and paper, A Security Kernel Based on the Lambda Calculus independently recognizes the equivalence between the lambda calculus and capability computation, and shows how to use the Scheme language as the kernel of a secure capability system. Similar in philosophy to the Trusty Scheme work that AutoDesk never released.
Mozart and E are related in an astonishing number of ways. They have Flat Concurrent Prolog as a common ancestor. Mozart has been pursuing an apparently similar course regarding concurrency, semi-transparent distribution, and partial-failure handling. Recently, the Mozart folks have been exploring secure distributed computing based on the same premise as E: The recognition that object references in our underlying formalism already have capability-nature. In addition, the Mozart folks have even been exploring agoric computing ideas, and have been creating and applying derivative intruments to this domain!
DropletsTM was conceived with the aim of creating an E-like capability environment based on the current WWW infrastructure and client browsers. In this environment, programmers can reason about the security of their web application in the same way that they reason about the security of an E application. The Waterken DropletsTM software supports the ERTP, allowing programmers to deploy Java smart contracts much like those written in E.
Related to Crypto
Many of the relevant threads brewing in the crypto world come together at the annual Financial Cryptography conferences, which always convene on the beautiful Caribean island of Anguilla. At the most recent -- FC'99 -- I briefly presented E.
Related to JVM-Based Languages
"Languages for the Java VM" is a rather extensive list, including a sublist of scripting languages. The language whose scripting language nature is closest to E is JPython, by the creator of Python. Indeed, Python was a major influence in the transition from Original E to the current E.
Related to E's Future Directions:
E currently provides cryptographically-based secrecy, authentication, and integrity, but not for untraceability or unlinkability. For example, if Alice transfers to Bob a "coin" issued by Carol, can Carol determine that the coin Bob "deposits" is one received from Alice? To hide this from Carol is unlinkability. Can Carol, in collaboration with, for example, the NSA, determine the locations of Alice or Bob? To hide this from Carol is untraceability. Currently, E provides neither.
Untraceability can be provided by a mix network. Zero Knowledge's Freedom network will shortly be deploying a high quality / high performance packet mix that initially provides only for client untraceability. E, however, is symmetrically peer-to-peer, so only symmetric untraceability is meaningful in E. Fortunately, E's Vat Location Service can be straightforwardly enhanced (along the lines of Bill's DataComm Thru Firewalls) to use the Freedom network to provide symmetric untraceability for E. Independent of E, Freedom is cool, and the client is free. Check it out.
Chaum's blinding is a mechanism for unlinkability. However, blinding only aids anonymity when transfering rights that are both exclusive and fungible. As explained in Contracts with Bearer, a non-exclusive transfer does not need blinding, and in a transfer of a non-fungible right, blinding cannot help. Blinding is currently entangled with patents, but should this situation change, we expect to support it in E. Blinding requires a blindable signature algorithm, and patent-free blinding requires a patent-free blindable signature algorithm. We expect to blind DSS.
E's contracting framework can accomodate a diversity of payment (or payment-like) instruments. However, to get started it's more important to actually support one payment instrument well than to potentially support many. We currently expect our first default payment instrument to be based on (or backed by) . We are currently also accepting donations in . Please sign up and help us out. Thanks.
Other privacy resources:
Unless stated otherwise, all text on this page which is either unattributed or by Mark S. Miller is hereby placed in the public domain.