Turing Complete Caveats

#1

A few thoughts:

I increasingly have been thinking of an ocap as just a function reference, which could itself just be a wrapper or closure around another function. In this way, the ultimate caveat is just code.

Imagine if I have a function openTheDoor(), and then if you were my dog walker, I might give you a reference to this function:

function () {
  if (isWednesday()) {
    openTheDoor()
  }
}

Now that seems simple enough as pseudo-code, but what about when the closure includes a variable according to its scope? If I wanted to let you take five oranges from my orange dispenser, I might give you a function like:

function() {
let limit = 5
  return function () {
    if (limit-- > 0) { dispenseOrange() }
  }
}()

The thing that strikes me about this is that it puts a burden of storing and running this code on the redeeming machine, and so there could be an attack where a delegated method holder composes very complex caveat code and partially redeems it, clogging up memory usage.

This relates very directly to the storage rent problems in Ethereum today.

I guess this implies that a redeeming machine needs to meter its computer usage, possibly with a gas model like Ethereum? Does anyone know of a JS or Jessie metering tool?

Also, kindof aside, but is related enough I’ll ask here: @tribble had mentioned how an english auction could be much more efficient than the current ethereum/bitcoin type transaction fee pricing model, could anyone link me to such an improved model?

1 Like
#2

I refer you to the general definition: “An ocap (object capability) is a transferrable, unforgeable authorization to use the object it designates.” So a function reference is indeed an ocap, but so is an object reference. More generally, there’s an isomorphism between objects and functions; we’ve built objects from functions (in E and Joule) and functions from objects (in Java and C#). But I think typically, an ocap refers to something with multiple available operations available to it (e.g., a file ocap has read, size, etc.) instead of just one (“run” the function).

You define a function ocap that attenuates access to another ocap (the orange dispenser). My primary concern about the attenuator is that you must run it in a place whose execution will faithfully execute the attenuation and not reveal the underlying unattenuated ocap.

In any case, yes it does indeed need metering of execution. The Agoric Technical Overview describes the metering approach, and there’s a currently-internal document that describes somewhat more detail. Two plausible approaches are 1) a modified runtime that does metering and 2) a rewrite step that inserts metering calls into the Jessie code before it runs. Those would be inserted at each basic block, for example. The rewriting is very similar to what Vitalik planned for code generation for ewasm.

As for the fee pricing, that’s a blog post in the queue to be written :). Happy to talk about it offline until then though.

2 Likes
#3

Back at the earlier Agorics, Inc., we had a nice introduction to various auction institutions. That might be a useful thought provoker :slight_smile:

1 Like