-
Notifications
You must be signed in to change notification settings - Fork 2
Contract specification
This file should act as specification to the Solidity contracts in the repository.
Contracts: WorkerDispatcher
The contract is stored in Ethereum and is an agreement between client and worker. Workers are included right from the start of the contract. The contract is valid for a certain time period. At the end of the contract the performance of the worker is reported to the main contract.
- Time period (for how long the contract is valid). This is specified in the
endvariable, which is the block number in which the contract ends. - Redundancy (how many workers?), NIY
- Payment (where’s my money, bitch?), NIY (
price). This is specified as the price in wei per block. - Type of application, NIY
- Worker pubkey,
worker - Testers’ pubkeys,
testers
A contract is purchased by a client from the system.
- List of workers and their data,
workers - Worker -> Register Worker (worker data)
- Client -> Request work contract (requirements) -> info to create contract
Worker struct contains
- Price for a specific time interval. Suggested interval is price per blocktime.
- Max length - maximum amount of time worker is willing to work for specified price, given as number of blocks
- Type of application, NIY
- Uptime, NIY
- Pubkey
buyContract(redundancy, length)
This function must be called with an appropriate amount of ether.
If the value of ether is too low the function will return a non valid address.
If too much ether is provided, the excess will be returned to the sender.
registerWorker()
Registers workers as available for work.
A tester is a special kind of worker which makes sure other workers are behaving according to the contract they are working on. They report their results to the contract between client and worker. When a contract expires, the results are reported to the Main Contract.
When a “client worker contract” is created testers are assigned.
A future improvement could be testers that are dynamically assigned throughout the length of the “client worker contract”.
Supposed flow for the application:
The first thing that should happen is that a Worker registers for work by communication with WorkerDispatcher. Workers can register at any time, and as soon as they are in the main contract they are waiting for work to be assigned to them.
A Client can then contact the network requesting work to be performed. The Client supplies the info needed and sends payment with the transaction. The network responds by creating a new WorkAgreement contract which includes the client, the worker and the testers. Does it include the ether to be used as payment? The Worker does not yet know that it has been assigned anything, and the client doesn’t know the IP of the worker. The Client then sends a message to the workers pubkey over Whisper notifying about the contract and requesting the IP. The WorkAgreement contract is initiated. What does this mean?.
This section should also include that both the Client and Worker must have python things running.
The WorkAgreement now runs its course. When the contract is done the results are reported back to the WorkerDispatcher contract and the assigned worker(s) get reputation in how well they have done.