Add drone RFC #1754
Add drone RFC #1754
Conversation
rfcs/0010-stamps.md
Outdated
|
|
||
| ## Example usage | ||
|
|
||
| Creator of on-chain game tic-tac-toe hosts a drone that responds to airdrop |
There was a problem hiding this comment.
BYOD seem tedious and very anti-chain. Perhaps an account can signal somehow that it's willing to pay the transaction fee for certain kinds of instructions, so joe public can get bootstrapped without using the s word (server that is).
There was a problem hiding this comment.
I agree. The general theme of Solana has been to move any off-chain functionality onto the chain. I see this stamps technique as sufficient, not ideal. In the current system, the fee is collected before the instruction is executed. We'd need to add another "who's buying?" entrypoint. A separate RFC? Perhaps even described as one intending to render this one obsolete?
There was a problem hiding this comment.
If stamps are not ideal, what is driving this RFC? Can we wait until we can implement the ideal?
There was a problem hiding this comment.
What's driving the RFC is that the Tabletops release should require fees for all transactions but wanting to continue offering on-chain games that can be played by users without any tokens. This RFC offers a convention for doing that without any rearchitecture.
There was a problem hiding this comment.
@garious, so the drone can always pre-sign the transaction with a key to just pay the the fee and have the user sign the other key for actual execution
There was a problem hiding this comment.
Are you paraphrasing this RFC?
There was a problem hiding this comment.
I don't see the point of the user signature. In this example, they are being given a game instance.
There was a problem hiding this comment.
@garious upon closer inspection, yes :). I think the "stamp" wording is confusing. The functional part is multiple signatures per transaction, and instructions referencing any subset of the transaction keys. It's hard to infer that from the rfc
There was a problem hiding this comment.
I don't see the point of the user signature. In this example, they are being given a game instance.
@garious if the original program requires the signature for the instruction's 0 key, the user would supply it. It would be up to the program.
There was a problem hiding this comment.
@aeyakovenko, I don't see what problem is solved with a user signature. Maybe there's something I can do to clarify the scope of the RFC?
|
@CriesofCarrots |
|
@mvines, do you approve of the method described by this RFC? |
|
Yeah what we discussed on the call sounds good. I don't see that as being an exact 1-1 with what's current in this RFC but I get the intent that that's good enough for me. Filed #1786 for giving this a try sometime soon-ish |
|
Good point, we discussed the possibility of a signing service being a more general purpose solution. That method might not use the term "stamp" or might use it with a different meaning such as, "stamping transactions with a signature after validation." Let's leave this PR open for now. I'd prefer to rewrite it than to have two RFCs, only one which is acknowledged in practice. |
| implement the existing drone, for example, it may only accept transaction data | ||
| with a `SystemProgram::Move` instruction transferring only up to a certain | ||
| amount of tokens. If the drone accepts the transaction, it shall return an | ||
| `Ok(Signature)` where `Signature` is a signature of the transaction data using |
There was a problem hiding this comment.
There need to be a way for the user of the drone to figure the drone's public key as well for inclusion in the transaction, if the drone is only going to return a Signature.
There was a problem hiding this comment.
Yes, like it's URL it could be static and published. Alternatively, the drone's API can include a method for querying it.
| the ledger. The client may do this maliciously or simply because it thinks the | ||
| first request was dropped. The drone should not simply query the cluster to | ||
| ensure the client has not already received an airdrop. Instead, it should use | ||
| `last_id` to ensure the previous request is expired before signing another. |
There was a problem hiding this comment.
How does one determine the age of a last_id?
There was a problem hiding this comment.
We don't offer a good way right now. We need a light client RFC for clients that just want to do PoH verification using a hash of each entry's transactions. This drone would be a light client and so would keep a recent_ids queue like the bank does. If the user's last_id is in the queue, it's not too old.
| ### Denial of Service | ||
|
|
||
| If the transaction data size is smaller than the size of the returned signature | ||
| (or descriptive error), a single client can flood the network. Considering |
There was a problem hiding this comment.
I don't follow how a single client could flood the network in this case?
There was a problem hiding this comment.
Say the input size was half the output size. Then a client can send 1/2 gbps of requests and see the drone flood the network 1 gbps of response data, preventing anyone else from getting responses.
Goal
The goal of this RFC is to define an airdrop mechanism that authorizes funds
for a particular use.
Background
To run an on-chain program, a client must first acquire tokens to pay a Solana
cluster a transaction fee to instantiate the program. To acquire the tokens,
the client might request them from a special client called a drone.
Problems
to simply keep them.
one to load the program.
Summary of Changes
Added RFC to propose a new term "stamp" to formalize a convention of sharing a signed transaction to authorize users to run programs without first needing tokens.