Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple method invocation messages #320

Closed
whyrusleeping opened this issue Apr 20, 2018 · 3 comments
Closed

Multiple method invocation messages #320

whyrusleeping opened this issue Apr 20, 2018 · 3 comments

Comments

@whyrusleeping
Copy link
Member

I think it would be really great if we were able to submit multiple method invocations per message. This would make quite a few 'smart contract programming' UXs much nicer.

We definitely don't have to do this right away, but its worth considering for launch.

@whyrusleeping
Copy link
Member Author

I'm thinking that this will be more and more important to making filecoin work well. users of the network will want to make many invocations at a time (posting bids, making deals, etc), and having to include a 65 byte signature as well as the overhead of several other fields per call will hurt.

I propose changing the Message type to:

type Message struct {
        Sig Signature 
        Nonce uint64
        GasPrice *TokenAmount

        Invocations []Invocation
}

type Invocation struct {
        To Address `json:"to"`
        Value *TokenAmount
        GasLimit Integer
        Method string
        Params []byte
}

@phritz
Copy link
Contributor

phritz commented Jun 7, 2018

Makes sense to me. WRT nomenclature I think I'd prefer to preserve the notion that a message is a transaction is an invocation, meaning maybe call the outer thing MessageSet and the inner thing a Message. The idea that message is an actor invocation goes pretty deep.

@whyrusleeping
Copy link
Member Author

@phritz that seems reasonable, though i'm not a fan of MessageSet for the name of the outer thingy.

Also, After running some calculations on total storage capacity over time, I think this is a definite must have for release. the overhead of sending many messages for bids, asks, deals, commits, etc is very non-trivial.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants