Gems: Pre-Alpha Development Update
Please consider joining our Telegram and joining the conversation
With much enthusiasm, the Gems team has been developing the Gems Platform and Gems Protocol.
Building Gems, we face many challenges, including how to store and retrieve proprietary datasets, keep track of tasks, and prevent malicious actors from abusing our platform — all while aiming to reduce transaction costs throughout the network by limiting writes to the blockchain. Today, we release our first pre-alpha demo. The final release will be open sourced and is continually improving. At its core, Gems connects researchers and job requesters through the blockchain, and this pre-alpha development update reflects that. We look forward to sharing more updates coming soon.
In our technology demo, we create a decentralized application that assigns tasks to miners, creates a due date for the work and keeps track of task completions. The demo maintains the core mission of Gems, while not having all the features we envision. We prioritized heavily to achieve the core functionality while setting us up for further advancements. In this article, we give a high level overview of our first pre-alpha release of the Gems Platform with a focus on the technology and methods used to build it.
Frontend
Imagine an organization wants miners to label a photo with the best 1 sentence description for the photo. Another organization wants miners to translate words from english to french, and so on. With this in mind, we built a user interface for miners to look at jobs, decide a job to work on, and then complete tasks for that job.
To create the interface we chose to use the Truffle Framework, web3.js, React and Redux. Truffle allows us to easily deploy and test contracts. We can call functions on these contracts client-side using Truffle and web3.js libraries, allowing us to send and retrieve data to the blockchain. This is imperative for future tasks interfaces or modules that will be built. Using React allows us to reuse components we build and update them as we get new tasks and jobs. Ultimately, we hope to create a product that can be extended for the future. Logging into the platform is done with MetaMask currently, but we are exploring other alternatives to help onboard people to blockchain. It is important to note, we chose to build a web interface first, to allow the greatest number of miners to use our service.
Backend
In our demo, there are Jobs and Tasks. A Job is the general work a requester wants done. An example Job, would be “label photos”, “translate text”, etc. Jobs have many tasks. A Task has the specific photo, text, etc. to be labeled, translated, etc. In this demo we create the first hypothetical Job Contract for an organization. It is the Job Contract’s responsibility to keep track of who Tasks are assigned to, if they are completed or not, and where the results are. To accomplish this, the Jobs Contract has a Task Struct.
struct Task {
uint id;
string description;
bool completed;
address miner;
uint dueDate;
bool assigned;
}Task[] public tasks;
The Task Struct contains details about the task like its due date, if a miner was assigned to it, if it has been completed, etc. The Jobs Contract stores an array of Tasks, aptly names Tasks. For our technology demo, we chose to store the Tasks on the blockchain, with the actual Task as its description. This is fine because our dataset for our demo and first job is public.
Result on Blockchain
Requesters we have talked with oftentimes have proprietary datasets and want privacy. The Task Struct will link to an external off-chain JSON that contains information regarding the task. Permissions for accessing the information will have to be managed and restricted to the miner and verifier assigned to each task.
Assigning a Task
The Job Contract is responsible for assigning tasks to miners. In our technology demo, no two miners will be assigned the same task at the same time, because we want 1 answer for each question. Miners should also not be assigned to completed tasks. When deciding which task to assign a miner we iterate over the list of tasks and find the first non completed task that has either a) never been assigned or b) has been assigned but is past the due date. We then assign the task to the miner requesting a task and keep track of the assignation in a map for easy access.
uint length = tasks.length;
for (uint i = 0; i < length; i++) {
var taskDue = checkTaskDue(tasks[i].dueDate);
// assign the first incomplete task that has never been assigned or is past due
if (tasks[i].completed == false && (tasks[i].miner == address(0) || taskDue)) {
// assign task to miner
assignTaskMiner(tasks[i].id, msg.sender);
// return the task
return getTask(i);
}
}One issue that may occur, is what happens if two people need a new task at the same time. What if they are assigned the same task? In a centralized application, this would be prevented using a lock or a mutex. Inspired by this, we can prevent race conditions when the network becomes larger.
Due Date
Imagine if there was no due date for the task. People could reserve the task for hours, days, weeks. The job would never be finishable if there was just 1 bad, sleepy or forgetful actor. To prevent this abuse, we set a due date on each task, so people do not hold onto a task over night or for hours. We set the due date arbitrarily for ~15 minutes in the demo using block timestamps. Block timestamps are not 100% accurate. However, for the demo, the due date does not need to be precise. The demo task miners are completing is very simple and should take only a matter of seconds. We encourage miners to complete tasks quickly and not wait for the last second or risk having their task forfeited. Centralized applications certainly allow for easier precision in times, but for our demo, we don’t foresee any problems with the due date. It is important for our projects mission to make sure miners receive fair treatment. Through client side JavaScript, we will actively monitor if miners tasks are being forfeited and if they are submitting tasks post forfeit. If a sizable amount of miners are adversely affected, we will consider prioritizing a more accurate due date mechanism.
We are extremely excited tackling our current challenges! We look forward to more updates. Next on the roadmap is:
- Implementing the Gems Payment Mechanism and Payment Channels to reduce gas costs
- Implementing and testing verification methods.
Interested in working with Gems or hearing more?
- Follow Our Twitter @Gems
- Visit Our Website Gems.org
- Join Our Telegram
- Read our White Paper
- Follow our Blog
- Email: hello[@]Gems[dot]org
