blockworks-foundation
/
solana
mirror of https://github.com/blockworks-foundation/solana.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Bring drone description into the present

This commit is contained in:
Greg Fitzgerald 2018-12-12 11:25:03 -07:00
parent 9f9c5fcf10
commit 504bf4ba84
1 changed files with 14 additions and 41 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

55
book/src/drones.md
View File

@ -1,47 +1,20 @@
# Drone 1.0: A Signing Service
# Creating Signing Services with Drones
The goal of this RFC is to define a microservice called a *drone*, which acts
as custodian of a user's private key. In its simplest form, it can be used to
This chapter defines an off-chain service called a *drone*, which acts as
custodian of a user's private key. In its simplest form, it can be used to
create *airdrop* transactions, a token transfer from the drone's account to a
client's account.
## Background
At the time of this writing, Solana contains an undocumented microservice
called a drone. A client sends that drone a request for tokens and it then
interacts with the Solana cluster directly to put the airdrop transaction on
the ledger. Once confirmed, the drone returns its signature so that a client
may also confirm the transaction.
The intent of the current design was that it be used by clients wanting to
test-drive the Solana testnet. We did not intend for it to be used in mainnet,
but recently we found variations of it are generally useful and so offer an
updated design. Specifically, we have found that program owners may want to
publish a drone such that potential program users may instantiate their
programs without first owning any tokens. The program owner can use the
existing drone to enable these users, but the approach is unsatisfying for a
number of reasons:
1. Once the client has tokens to instantiate the program, the client may choose
to simply keep them.
2. Instantiating a program requires two transaction fees - one for the airdrop
and one to instantiate the program.
3. The drone uses its own resources to interact with the Solana cluster
directly. This artificially limits the number of users it can serve and
opens the drone to DoS attacks.
## Signing Service
To solve the problems described above, the drone shall be reduced to a simple
signing service. It shall listen for requests to sign *transaction data*. Once
received, the drone should validate the request however it see fit. To
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
the drone's private key. If it rejects the transaction data, it should return a
`DroneError` describing why.
A drone is a simple signing service. It listens for requests to sign
*transaction data*. Once received, the drone validates the request however it
sees fit. It may, for example, only accept transaction data with a
`SystemInstruction::Move` instruction transferring only up to a certain amount
of tokens. If the drone accepts the transaction, it returns an `Ok(Signature)`
where `Signature` is a signature of the transaction data using the drone's
private key. If it rejects the transaction data, it returns a `DroneError`
describing why.
## Examples
@ -67,8 +40,8 @@ airdrop to distribute its tokens to millions of users over just a few seconds.
That drone cannot spend resources interacting with the Solana cluster. Instead,
the drone should only verify the client is unique and human, and then return
the signature. It may also want to listen to the Solana cluster for recent
entry IDs to support client retries and to ensure the airdrop is targeting
the desired cluster.
entry IDs to support client retries and to ensure the airdrop is targeting the
desired cluster.
## Attack vectors
@ -81,7 +54,7 @@ reference a recent one.
Note: to listen for new entry IDs assumes the drone is either a fullnode or a
*light* client. At the time of this writing, light clients have not been
implemented and no Solana RFC describes them. This document assumes one of the
implemented and no proposal describes them. This document assumes one of the
following approaches be taken:
1. Define and implement a light client