Illustrating gas usage
16 views
Skip to first unread message
Christopher Lemmer Webber
Jun 5, 2020, 5:03:50 PM6/5/20
to fr...@googlegroups.com
Towards the end of the Friam call today, we had a bit of a conversation
about gas, and the particularly tricky problem (especially across
vat-or-equivalent boundaries) of the kind of extra things you have to
worry about in terms of trickery... if Mallet doesn't want to spend gas
on talking to Alice, but Mallet knows that Bob has plenty of gas for
communicating with Alice, can Mallet spend a cheaper amount of gas on
talking to Bob to trick Bob into spending Bob's gas on Mallet's
communication-with-Alice situation? Given the amount of proxying that
tends to happen in ocap systems, it seems to be a concern.
Various approaches were discussed, but in general it's very hard for me
to imagine how they work and how safe they are. I expressed that it
would be nice to see if we can extend the grannovetter diagram to
include gas tanks, eg maybe gas tanks could be attached to message
arrows, or to vats, or pumped into a vat turn from a vat's reserve, or
etc etc. If we wanted to keep track of "who's gas" was being spent
(even if just so we can figure out if someone is being screwed) we could
"color" the fluid. (On IRC, Baldur suggested that if two sources of
money were mixed, a stripe pattern could be used.)
I haven't done this, but it seems like a good idea to not completely
forget, but I expressed hesitation on IRC about sending yet another
thread to cap-talk, so Baldur suggested sending here. Good point, now I
can't be blamed for further overloading friam, right?
Sending this before everyone starts charging me gas (or stamps) for
posting to these lists,
- Chris
about gas, and the particularly tricky problem (especially across
vat-or-equivalent boundaries) of the kind of extra things you have to
worry about in terms of trickery... if Mallet doesn't want to spend gas
on talking to Alice, but Mallet knows that Bob has plenty of gas for
communicating with Alice, can Mallet spend a cheaper amount of gas on
talking to Bob to trick Bob into spending Bob's gas on Mallet's
communication-with-Alice situation? Given the amount of proxying that
tends to happen in ocap systems, it seems to be a concern.
Various approaches were discussed, but in general it's very hard for me
to imagine how they work and how safe they are. I expressed that it
would be nice to see if we can extend the grannovetter diagram to
include gas tanks, eg maybe gas tanks could be attached to message
arrows, or to vats, or pumped into a vat turn from a vat's reserve, or
etc etc. If we wanted to keep track of "who's gas" was being spent
(even if just so we can figure out if someone is being screwed) we could
"color" the fluid. (On IRC, Baldur suggested that if two sources of
money were mixed, a stripe pattern could be used.)
I haven't done this, but it seems like a good idea to not completely
forget, but I expressed hesitation on IRC about sending yet another
thread to cap-talk, so Baldur suggested sending here. Good point, now I
can't be blamed for further overloading friam, right?
Sending this before everyone starts charging me gas (or stamps) for
posting to these lists,
- Chris
Ben Laurie
Jun 6, 2020, 4:21:15 PM6/6/20
to friam
This seems like a completely artificial concern. Crypto (by which, of course, I mean cryptography) is cheap. No-one has worried about its cost for at least a decade.
Of course, I recognise that the term "gas" comes from a cult that thinks that making crypto expensive is somehow useful. My response is: don't do that.
--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/friam/87lfl1mdhn.fsf%40dustycloud.org.
Kevin Reid
Jun 6, 2020, 6:14:59 PM6/6/20
to fr...@googlegroups.com
On Sat, Jun 6, 2020 at 1:21 PM 'Ben Laurie' via friam <fr...@googlegroups.com> wrote:
This seems like a completely artificial concern. Crypto (by which, of course, I mean cryptography) is cheap. No-one has worried about its cost for at least a decade.Of course, I recognise that the term "gas" comes from a cult that thinks that making crypto expensive is somehow useful. My response is: don't do that.
The discussion was not about blockchains or any other crypto operations, but the general case of running computation on your resources on behalf of someone else sending you a request (or a program), and using "gas" as a policy for bounding the resources used by that.
Chris Hibbert
Jun 6, 2020, 8:37:29 PM6/6/20
to fr...@googlegroups.com
On 6/6/20 1:21 PM, 'Ben Laurie' via friam wrote:
> This seems like a completely artificial concern. Crypto (by which, of
> course, I mean cryptography) is cheap. No-one has worried about its cost
> for at least a decade.
>
> Of course, I recognise that the term "gas" comes from a cult that thinks
> that making crypto expensive is somehow useful. My response is: don't do
> that.
I'm currently working in an offshoot of that cult that is trying to
> This seems like a completely artificial concern. Crypto (by which, of
> course, I mean cryptography) is cheap. No-one has worried about its cost
> for at least a decade.
>
> Of course, I recognise that the term "gas" comes from a cult that thinks
> that making crypto expensive is somehow useful. My response is: don't do
> that.
marry ocaps with the advantages that cryptocurrencies seem to bring.
AFAICT, no one claims that the advantages come from the fact that it's
expensive. The benefits come from the shared visibility of the assurance
that the "computer" did the right thing. Those benefits are valuable
enough that the cost of replicated computation are worth it. The
mechanisms of replication include the use of cryptography, but the crypt
is neither the point of the computation, nor the cause of the cost. It's
unfortunate that its shortened form has been used a a nickname for the
field.
But maybe you knew that and were just yanking our chain.
And as Kevin pointed out, the equivalent of gas was present in KeyKos,
precisely because they were running computations on behalf of other people.
--
It is easy to turn an aquarium into fish soup, but not so
easy to turn fish soup back into an aquarium.
-- Lech Walesa on reverting to a market economy.
Chris Hibbert
hib...@mydruthers.com
Blog: http://www.pancrit.org
Twitter: C_Hibbert_reads
http://mydruthers.com
Ben Laurie
Jun 7, 2020, 9:55:17 AM6/7/20
to friam
On Sun, 7 Jun 2020 at 01:37, Chris Hibbert <hib...@mydruthers.com> wrote:
On 6/6/20 1:21 PM, 'Ben Laurie' via friam wrote:
> This seems like a completely artificial concern. Crypto (by which, of
> course, I mean cryptography) is cheap. No-one has worried about its cost
> for at least a decade.
>
> Of course, I recognise that the term "gas" comes from a cult that thinks
> that making crypto expensive is somehow useful. My response is: don't do
> that.
I'm currently working in an offshoot of that cult that is trying to
marry ocaps with the advantages that cryptocurrencies seem to bring.
AFAICT, no one claims that the advantages come from the fact that it's
expensive.
Errr. So why PoW?
The benefits come from the shared visibility of the assurance
that the "computer" did the right thing. Those benefits are valuable
enough that the cost of replicated computation are worth it. The
mechanisms of replication include the use of cryptography, but the crypt
is neither the point of the computation, nor the cause of the cost. It's
unfortunate that its shortened form has been used a a nickname for the
field.
But maybe you knew that and were just yanking our chain.
And as Kevin pointed out, the equivalent of gas was present in KeyKos,
precisely because they were running computations on behalf of other people.
You talked about the cost of *communication* not computation. Communication costs are negligible (unless you are wireless and battery driven, which I assume is not what you were talking about), so I am confused.
--
It is easy to turn an aquarium into fish soup, but not so
easy to turn fish soup back into an aquarium.
-- Lech Walesa on reverting to a market economy.
Chris Hibbert
hib...@mydruthers.com
Blog: http://www.pancrit.org
Twitter: C_Hibbert_reads
http://mydruthers.com
--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/friam/2cb99c2d-c88a-87ca-b0a6-0da7dcdf69fb%40mydruthers.com.
Chris Hibbert
Jun 7, 2020, 1:30:34 PM6/7/20
to fr...@googlegroups.com
On 6/7/20 6:55 AM, 'Ben Laurie' via friam wrote:
>> And as Kevin pointed out, the equivalent of gas was present in
>> KeyKos, precisely because they were running computations on behalf
>> of other people. >
> You talked about the cost of *communication* not computation.
> Communication costs are negligible (unless you are wireless and
> battery driven, which I assume is not what you were talking about),
> so I am confused.
In my most recent message (my only one here in a week) I mentioned
computation, not communication. Are you talking about something I said
earlier, or something someone else said? Ahh, yes. Your original reply
on this thread was to Christopher Lemmer Webber, and he had been talking
about gas in the context of communication.
On Fri, 5 Jun 2020, Christopher Lemmer Webber wrote:
> if Mallet doesn't want to spend gas on talking to Alice, but Mallet
> knows that Bob has plenty of gas for communicating with Alice, can
> Mallet spend a cheaper amount of gas on talking to Bob to trick Bob
> into spending Bob's gas on Mallet's communication-with-Alice
> situation? Given the amount of proxying that tends to happen in
> ocap systems, it seems to be a concern.
Few of the blockchain systems that I can think of actually charge for
communication costs, so I read Chris as using communication as a
metaphor for computation. "Bob has plenty of gas for communicating with
Alice" means Bob can afford to send messages to Alice and pay for the
resulting computation.
In the blockchain case, computation is expensive and communication is
relatively cheap, which is probably why sending packets isn't accounted
for in the gas economy. The first generation blockchains were all
stand-alone systems, so communication is literally outside their model.
... I should unpack that. Ethereum, BitCoin, ZCash, etc., each conceived
of as a collection of computers implementing a single computation,
represent stand-alone computers that receive inputs from the ether, and
write results to their own memory. The communication between the
components of each of these computation engines is outside the
computational model.
The systems that are integrating various kinds of IBC (as Cosmos is in
cooperation with Agoric) are considering ways of incentivizing the
relayers (the part of the design that supports communication). So, when
communication becomes part of the computation model, it seems we're also
adding it to the economics.
Chris
--
All sensory cells [in all animals] have in common the presence of
... cilia [with a constant] structure. It provides a strong
argument for common ancestry. The common ancestor ... was a
spirochete bacterium.
--Lynn Margulis (http://edge.org/q2005/q05_7.html#margulis)
> On Sun, 7 Jun 2020, Chris Hibbert <hib...@mydruthers.com> wrote:
> > AFAICT, no one claims that the advantages come from the fact that
> > it's expensive.
>
> Errr. So why PoW?
That was the first successful design. Few later systems used that approach.
> > AFAICT, no one claims that the advantages come from the fact that
> > it's expensive.
>
> Errr. So why PoW?
>> And as Kevin pointed out, the equivalent of gas was present in
>> KeyKos, precisely because they were running computations on behalf
>> of other people. >
> You talked about the cost of *communication* not computation.
> Communication costs are negligible (unless you are wireless and
> battery driven, which I assume is not what you were talking about),
> so I am confused.
computation, not communication. Are you talking about something I said
earlier, or something someone else said? Ahh, yes. Your original reply
on this thread was to Christopher Lemmer Webber, and he had been talking
about gas in the context of communication.
On Fri, 5 Jun 2020, Christopher Lemmer Webber wrote:
> if Mallet doesn't want to spend gas on talking to Alice, but Mallet
> knows that Bob has plenty of gas for communicating with Alice, can
> Mallet spend a cheaper amount of gas on talking to Bob to trick Bob
> into spending Bob's gas on Mallet's communication-with-Alice
> situation? Given the amount of proxying that tends to happen in
> ocap systems, it seems to be a concern.
communication costs, so I read Chris as using communication as a
metaphor for computation. "Bob has plenty of gas for communicating with
Alice" means Bob can afford to send messages to Alice and pay for the
resulting computation.
In the blockchain case, computation is expensive and communication is
relatively cheap, which is probably why sending packets isn't accounted
for in the gas economy. The first generation blockchains were all
stand-alone systems, so communication is literally outside their model.
... I should unpack that. Ethereum, BitCoin, ZCash, etc., each conceived
of as a collection of computers implementing a single computation,
represent stand-alone computers that receive inputs from the ether, and
write results to their own memory. The communication between the
components of each of these computation engines is outside the
computational model.
The systems that are integrating various kinds of IBC (as Cosmos is in
cooperation with Agoric) are considering ways of incentivizing the
relayers (the part of the design that supports communication). So, when
communication becomes part of the computation model, it seems we're also
adding it to the economics.
Chris
--
All sensory cells [in all animals] have in common the presence of
... cilia [with a constant] structure. It provides a strong
argument for common ancestry. The common ancestor ... was a
spirochete bacterium.
--Lynn Margulis (http://edge.org/q2005/q05_7.html#margulis)
Christopher Lemmer Webber
Jun 7, 2020, 3:47:59 PM6/7/20
to fr...@googlegroups.com
'Ben Laurie' via friam writes:
> Errr. So why PoW?
So... I think you are misunderstanding the context in which I am
interested in gas. It does not have to do with cryptocurrencies,
cryptography, or proof of work (no matter how much or how little those
systems may be mixed in). It has to do with resource usage.
Kevin Reid writes:
> On Sat, Jun 6, 2020 at 1:21 PM 'Ben Laurie' via friam <
On the call, when I brought up gas, I was talking about the desire to
run a virtual worlds game where players were able to contribute fun game
features that we can install without them being able to take out the
whole game server's resources (space *or* time).
One could even be playing singleplayer and want to install some
completely untrusted game enemies which are restricted such that they
cannot take out the server. That's an example where no cryptography
would have to be involved even on a communication layer, because it's
all local.
The KeyKOS use case is more relevant. But "gas" seems to be the common
place term for the core idea.
I think, not unlike "smart concepts", this is yet another concept which
is applicable outside of blockchain technology, but the blockchain use
case has gotten so publicly popular that it's easy to assume all
relevant uses are within that context.
Blockchains are barely ever on my mind. Interesting stuff, but the uses
I have for them are very small given their high costs and the other ways
I think we can accomplish things in most cases. So if I make a post,
unless I say it's about blockchains, it's best not to assume it is.
- Chris
> Errr. So why PoW?
So... I think you are misunderstanding the context in which I am
interested in gas. It does not have to do with cryptocurrencies,
cryptography, or proof of work (no matter how much or how little those
systems may be mixed in). It has to do with resource usage.
Kevin Reid writes:
> On Sat, Jun 6, 2020 at 1:21 PM 'Ben Laurie' via friam <
> fr...@googlegroups.com> wrote:
>
>> This seems like a completely artificial concern. Crypto (by which, of
>> course, I mean cryptography) is cheap. No-one has worried about its cost
>> for at least a decade.
>>
>> Of course, I recognise that the term "gas" comes from a cult that thinks
>> that making crypto expensive is somehow useful. My response is: don't do
>> that.
>
>
>> This seems like a completely artificial concern. Crypto (by which, of
>> course, I mean cryptography) is cheap. No-one has worried about its cost
>> for at least a decade.
>>
>> Of course, I recognise that the term "gas" comes from a cult that thinks
>> that making crypto expensive is somehow useful. My response is: don't do
>> that.
>
> The discussion was not about blockchains or any other crypto operations,
> but the general case of running computation on your resources on behalf of
> someone else sending you a request (or a program), and using "gas" as a
> policy for bounding the resources used by that.
Yes, this is the problem domain I am looking at.
> but the general case of running computation on your resources on behalf of
> someone else sending you a request (or a program), and using "gas" as a
> policy for bounding the resources used by that.
On the call, when I brought up gas, I was talking about the desire to
run a virtual worlds game where players were able to contribute fun game
features that we can install without them being able to take out the
whole game server's resources (space *or* time).
One could even be playing singleplayer and want to install some
completely untrusted game enemies which are restricted such that they
cannot take out the server. That's an example where no cryptography
would have to be involved even on a communication layer, because it's
all local.
The KeyKOS use case is more relevant. But "gas" seems to be the common
place term for the core idea.
I think, not unlike "smart concepts", this is yet another concept which
is applicable outside of blockchain technology, but the blockchain use
case has gotten so publicly popular that it's easy to assume all
relevant uses are within that context.
Blockchains are barely ever on my mind. Interesting stuff, but the uses
I have for them are very small given their high costs and the other ways
I think we can accomplish things in most cases. So if I make a post,
unless I say it's about blockchains, it's best not to assume it is.
- Chris
Ben Laurie
Jun 8, 2020, 7:53:14 AM6/8/20
to friam
I see. Your email was about "talking to" people, which seems like a different thing from this.
This example is interesting because presumably for many practical examples, the computation has to complete in a timely way to avoid screwing up the user experience, so it doesn't seem like you have a whole lot of choice around providing the resource - the interesting question is who pays for it?
One could even be playing singleplayer and want to install some
completely untrusted game enemies which are restricted such that they
cannot take out the server. That's an example where no cryptography
would have to be involved even on a communication layer, because it's
all local.
The KeyKOS use case is more relevant. But "gas" seems to be the common
place term for the core idea.
I think, not unlike "smart concepts", this is yet another concept which
is applicable outside of blockchain technology, but the blockchain use
case has gotten so publicly popular that it's easy to assume all
relevant uses are within that context.
Blockchains are barely ever on my mind. Interesting stuff, but the uses
I have for them are very small given their high costs and the other ways
I think we can accomplish things in most cases. So if I make a post,
unless I say it's about blockchains, it's best not to assume it is.
Verifiable append only logs do all of the useful things and are very cheap. :-)
- Chris
--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/friam/87h7vmmzde.fsf%40dustycloud.org.
Bill Frantz
Jun 9, 2020, 9:19:38 PM6/9/20
to fr...@googlegroups.com
On 6/7/20 at 3:47 PM, cwe...@dustycloud.org (Christopher Lemmer
KeyKOS meters. One glaring difference is the assumption with gas
that if you run out during the middle of a computation, you
don't just coast to the side of the road (in KeyKOS stop
suddenly with the computation frozen and restartable) giving you
the option of hiking into town with a gas can, adding more gas
and continuing on to your destination. Instead, the results of
your computation are discarded -- think data base abort -- and
you get to start over.
Indeed, with the KeyKOS meters, you could implement the abort
policy, but the general idea was to allow restart.
Cheers - Bill
-----------------------------------------------------------------------
Bill Frantz | There's nothing so clear | Periwinkle
(408)348-7900 | as a design you haven't | 150 Rivermead
Rd #235
www.pwpconsult.com | written down. - Dean Tribble| Peterborough,
NH 03458
Webber) wrote:
>The KeyKOS use case is more relevant. But "gas" seems to be the common
>place term for the core idea.
There's a lot in common between what I think "gas" is and the
>The KeyKOS use case is more relevant. But "gas" seems to be the common
>place term for the core idea.
KeyKOS meters. One glaring difference is the assumption with gas
that if you run out during the middle of a computation, you
don't just coast to the side of the road (in KeyKOS stop
suddenly with the computation frozen and restartable) giving you
the option of hiking into town with a gas can, adding more gas
and continuing on to your destination. Instead, the results of
your computation are discarded -- think data base abort -- and
you get to start over.
Indeed, with the KeyKOS meters, you could implement the abort
policy, but the general idea was to allow restart.
Cheers - Bill
-----------------------------------------------------------------------
Bill Frantz | There's nothing so clear | Periwinkle
(408)348-7900 | as a design you haven't | 150 Rivermead
Rd #235
www.pwpconsult.com | written down. - Dean Tribble| Peterborough,
NH 03458
Christopher Lemmer Webber
Jun 19, 2020, 10:29:03 AM6/19/20
to fr...@googlegroups.com
We don't appear to have a Friam topic yet this week, so how about this
one?
I might even be able to bust out my wacom tablet and we could see if we can
manage to mock it up live...
Would also like to talk about how the "resolver/reciever" in CapTP fares
against DDoS amplification attacks. I think actually pretty well, but
I'd love to explore it. Gas is one solution, but introduces other
challenges, so it would be interesting to see how it does pre/post gas.
one?
I might even be able to bust out my wacom tablet and we could see if we can
manage to mock it up live...
Would also like to talk about how the "resolver/reciever" in CapTP fares
against DDoS amplification attacks. I think actually pretty well, but
I'd love to explore it. Gas is one solution, but introduces other
challenges, so it would be interesting to see how it does pre/post gas.
Matt Rice
Jun 19, 2020, 12:05:26 PM6/19/20
to friam
On Fri, Jun 19, 2020 at 2:29 PM Christopher Lemmer Webber
<cwe...@dustycloud.org> wrote:
>
> We don't appear to have a Friam topic yet this week, so how about this
> one?
>
> I might even be able to bust out my wacom tablet and we could see if we can
> manage to mock it up live...
Another source of inspiration could come from GIS,
<cwe...@dustycloud.org> wrote:
>
> We don't appear to have a Friam topic yet this week, so how about this
> one?
>
> I might even be able to bust out my wacom tablet and we could see if we can
> manage to mock it up live...
where there has been a lot of work in mapping e.g. traffic flow.
that isn't quite the same, but has at least some amount of overlap.
Anita Graser has blogged quite extensively on visualizing movement
using open source tools.
https://anitagraser.com/movement-data-in-gis/
> --
> You received this message because you are subscribed to the Google Groups "friam" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/friam/874kr7ceoi.fsf%40dustycloud.org.
> You received this message because you are subscribed to the Google Groups "friam" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
Christopher Lemmer Webber
Jun 19, 2020, 1:02:46 PM6/19/20
to fr...@googlegroups.com, Matt Rice
Matt Rice writes:
> On Fri, Jun 19, 2020 at 2:29 PM Christopher Lemmer Webber
> <cwe...@dustycloud.org> wrote:
>>
>> We don't appear to have a Friam topic yet this week, so how about this
>> one?
>>
>> I might even be able to bust out my wacom tablet and we could see if we can
>> manage to mock it up live...
>
>
> Another source of inspiration could come from GIS,
> where there has been a lot of work in mapping e.g. traffic flow.
> that isn't quite the same, but has at least some amount of overlap.
>
> Anita Graser has blogged quite extensively on visualizing movement
> using open source tools.
> https://anitagraser.com/movement-data-in-gis/
That does seem like an interesting way of showing things.
> On Fri, Jun 19, 2020 at 2:29 PM Christopher Lemmer Webber
> <cwe...@dustycloud.org> wrote:
>>
>> We don't appear to have a Friam topic yet this week, so how about this
>> one?
>>
>> I might even be able to bust out my wacom tablet and we could see if we can
>> manage to mock it up live...
>
>
> Another source of inspiration could come from GIS,
> where there has been a lot of work in mapping e.g. traffic flow.
> that isn't quite the same, but has at least some amount of overlap.
>
> Anita Graser has blogged quite extensively on visualizing movement
> using open source tools.
> https://anitagraser.com/movement-data-in-gis/
Christopher Lemmer Webber
Jun 19, 2020, 3:43:21 PM6/19/20
to fr...@googlegroups.com
Great Friam this week. I've attached a (only slightly) cleaned up
drawing from working through how to annotate the Grannoveter diagram for
gas. Here you can see gas tanks added to messages and a proxy object.
On the perimeter I've drawn some ideas that came up:
- Some tickets based on our "paying cash for carnival tickets"
conversation. (The summary of that being: at a carnival I might pay
cash for tickets which I can use at the carnival, hand to less
trustworthy teenagers who might not be trusted for cash. Nonetheless
that might be how I go on local rides. This exchange is nonetheless
not illustrated.)
- A tank with stripes representing "mixed sources" of gas.
I took some notes during the call; they're pretty messy. I'm attempting
to distill them briefly below; feel free to ask for clarifications.
!!!notes start below!!!
Three kinds of "gas":
- global currency
- local boundary currency (eg "carnival tickets")
- general deterministic cost for space/time and etc against some
abstract VM
So now in our scenario:
- Alice has bought some CTickets using GlobalBux.
- Alice hands Bob a reference to Carol allocated with some CTickets.
- C converts CTickets into amount of VM instructions / memory
Approaches to "allocating gas"
- curry onto the reference to carol-for-bob ~directly
- via a proxy object
- some complicated cert chain thing (but can the gas then be extracted?)
- Apply it as an additional purse-argument
(easiest path for bob to go spend that money elsewhere... not great)
- Have the handoff be the place with the "curried with money"
reference, a gift of Carol-plus-gas waiting for B at C (could compose
nicely with cert-handoff approach). I think this was the group
general preference.
- callback to get gas from alice (possibly leaks too much info to the
mint and seemed complicated?)
some mockup of some cert:
{"to": C,
"for": B,
"checkCallback": (sealed-to-C <exported-purse-from-A>),
"accessTo": <Carol>}
Alan about the cert above: "This is too complicated to mock up on a
call" (maybe we can do so here)
This cert could be made easier if A has "tickets" to C (bought with the
more universal currency)
What would using this look like in practice? Here's one where the gas
is "bound to the reference":
#+BEGIN_SRC racket
;; running in alice
(define gassy-bob
(with-tank bob (alice-tank.withdraw 20)))
(define gassy-carol-for-bob
(with-tank carol (alice-tank.withdraw 30)))
(on (<- gassy-bob.foo gassy-carol-for-bob)
(lambda (val)
...))
#+END_SRC
vs one where a gas purse is supplied as an additional argument
(but this also means Bob could go spend the gas elsewhere, and requires
a lot of understanding of what the "purpose of purse arguments" are):
#+BEGIN_SRC racket
;; running in alice
(define gassy-tank-for-bob-to-use-on-carol
(alice-tank.withdraw 30))
(on (<- (with-gas gassy-bob.foo (alice-tank.withdraw 20))
gassy-carol-for-bob
gassy-tank-for-bob-to-use-on-carol)
(lambda (val)
...))
#+END_SRC
Some concerns identified:
- How do you join the system and get your initial gas? Akin to how
you join a captp system anyway, use whatever mechanism that is
- eq? concerns and grant matcher
- Can Bob "extract" this version of Carol for the "raw carol"?
- Can Bob add gas to this Carol reference?
(to those last ones Alan says "think in terms of object references
first and certificate dynamics at a future point")
- Resuming vs re-entrancy?
- Spawning pre-empt'able/resumeable vats when you need them. You might
charge more for computation that suspends than ones where the whole
turn fails
- Implicit refund of gas or no?
- gas all the way down? do you have to pay gas to get gas?
(Alan brought up BGP as something that's handled this as "a protocol
nightmare, but in practice has been effective enough")
Thanks for the call anyone! I'm excited about passing gas!
Reply all
Reply to author
Forward
0 new messages