Golos • Core team is thrilled to share the latest news related to the blockchain development.
We’d like to present you a feature of workers that is being developed based on demand from the community. A third-party developer @denis4inet has joined us to accomplish this task for a bounty (approx. 60,000 GOLOS, the final reward amount to be announced after successful completion of the task).
The main goal of this post is to provide the necessary information to the end users, to describe possible technical issues and to give detailed scenarios with an actual roadmap. Below you will find a technical specification of the feature. This feature is being implemented for the new Golos blockchain as well as the current one.
One of the most important goals we want to achieve is to ensure the quality control of the development via workers (through technical specification and final work acceptance).
Technical specification for the development of workers
Please pay attention to the fact that any technical specification can be corrected and adjusted as a result of the further analysis and comparison of various proposed models of workers in different blockchain systems available.
The funds for workers will be replenished through:
Scenario # 1 - Task: The development proposal comes from community
Scenario # 2 - Task: The code is done and delivered by a worker
Scenario # 1
1. An incoming proposal from an active member of the community (for example, from a witness, a worker or any other user):
a. An incoming proposal from an active member of the community manifesting the implementation of any functionality at the expense of funds allocated from the pool.b. Voting and commenting on the proposal given by community members:
c. The author is capable of deleting his own proposal if his/her proposal has not received any approval yet.d. Transition to the stage of drafting the technical specification.
2. An incoming proposal from a sponsor:a. A proposal comes from someone who wants to fund its development (a sponsor).b. Blocking (or "freezing") of funds received from the sponsor on a special account linked to the specific task.c. Voting and commenting on the proposal by community members:
d. The sponsor is capable of deleting his own proposal if his proposal has not received any approval yet. The frozen funds will be transferred back to sponsor.e. Transition to the stage of drafting the technical specification.
For selected proposals the option “to fill out the technical specification” becomes available.
3. Technical specification development:
Drafting of the technical assignment is mandatory in order to prevent the possibility of refund when the work assigned to a worker is incomplete, as well as for work that does not comply with the technical specification.
a. An offer for the development of the technical specification is placed. The scheme for accepting this work is the following:
b. The witnesses vote for a proposal via voting on applications for development of the technical specification. Each vote of a witness must be accompanied by an explanation of the decision:
c. The blocking ("freezing") of a certain amount of the pool funds is allocated to:
d. Development and publication of technical specification.
e. Transition to the stage of the search for a worker which will execute the technical specification.
4. Performance stages:
a. The workers bid for technical tasks. The offer from a worker must contain the following information:
b. The author of the technical specification screens the incoming offers from workers and chooses the best candidate:
c. Possible additional funds from sponsors for the assignment:
In case of refusal to perform/skip the work in the process by the worker, the funds allocated to this task in the pool become "unfrozen" and get transferred to a free state. Any worker refund is not carried out.
d. The task can be executed by the worker only.
e. The worker must regularly publish the work updates in terms of reports which may include:
f. While work is being done, the witnesses can vote with remarks (50% +1 of the witnesses) to mark proposal as unfulfilled and unblock funds in the reward pool.g. The work done is accepted by the author of the technical specification. Compilation and publication of the act on acceptance of the work performed. An incomplete work (work in progress) can not be accepted.
h. Transition to the stage of reward payment.
5. Reward payment conditions:a. The signing of the act of acceptance by witnesses. The possible actions of witnesses:
b. In the event of approval of the final work by witnesses, the payments for the code delivery and for development of the technical specification are processed in accordance with a schedule of approved payments, or partly (from the "frozen" funds of the sponsors and also from the pool of rewards in accordance with the schedule of approved payments).
Scenario # 2
1. Submission of the application for payment for code delivery:a. An incoming proposal from a member of the community to pay for any functionality from funds allocated from the pool. The proposal must contain the following:
b. Voting and commenting:
c. The author is capable of deleting his own proposal if this proposal has not received any approval yet.d. After the end of voting, the application moves to the “reward” stage.
2. Reward payment conditions:
a. The signing of the act of acceptance by witnesses. The possible actions of witnesses:
b. In the event of approval of the final work by witnesses, the payment for the work and drafting of the technical specification is carried out from the pool of rewards in accordance with the schedule of approved payments, or partly (from the "frozen" funds of the sponsors and also from the pool of rewards in accordance with the schedule of approved payments).