Fragments Protocol & General Architecture

Fragments Protocol & General Architecture
This section describes the general architecture of the Fragments platform – how tasks
are handled and distributed, how payments are facilitated. The requester side (Task
Repository) and annotator side (Annotator App) are described here in general, with
the central Fragments dApp being described in more detail.
To see how micro-task apps can be developed and integrated to Task Repositories
and Annotator Apps on the Fragments platform and understand more detail about
mechanisms surrounding them, see Section 4.
Fragments Protocol. There are three main components: Task Repositories, De-
centralized Application (running on Ethereum blockchain) and Annotator Apps, as
shown in Figure 5. In a nutshell, the relationships and communication between them
are as follows.
Requesters set-up and maintain a Task Repository, where all data about their
tasks are stored. Task Repositories (Repos) advertise batches of tasks through the
Decentralized Application (dApp). Annotator Apps connect to the dApp to obtain
the available task batches. Once the Annotator picks a batch to work on, the Anno-
tator App connects directly to the Repo, to fetch task data and send the tasks back
completed. The dApp handles services such as progress tracking and payments.
The individual components are described in more detail be

Figure 5: An elementary overview of the Fragments platform architecture. Task
repositories store and provide task data. Annotators perform tasks in annotator
Apps. The dApp handles underlying services, such as payments and task batch
advertisement.
Development Phases
We know that time to market is crucial and at the same time, we would like to limit
expenses for Ethereum gas and our estimations indicate that 100-1,000 actions per
second will be performed on our platform, which might be challenging. (For example,
when the Cryptokitties app launched, Cryptokitties traffic made up over 20% of the
transactions on the Ethereum blockchain, causing overall transactions to slow down
and increase in cost. [15])
Therefore, we have split the development process into two phases as indicated in
Figure 5 – first, only the two most essential components of the dApp will be built
on Ethereum blockchain: Agreements, Stakes & Payments, and App Directory. The
remaining two components, Task Pool and Task Chain, will be run as off-chain apps
at first and as the project gains traction and Ethereum’s throughput increases, they
will be migrated to Ethereum blockchain as well.
To maintain transparency and trust in the Task Chain component during the
off-chain phase, a private blockchain will be mined and maintained by Fragments
team with the genesis file and an online inspector (using an interface similar to
Etherscan) available, so that all parties can verify the checksums on the Task Chain
or synchronize it to make sure the past data have not been tampered with. With
this approach, most of the tasks can be processed in real time, and can be scalable
without transaction fees induced by gas.
4 Micro-task Apps
This section describes how micro-task apps can be built on top of the Fragments
platform. More general description of the platform architecture is given in Section 3.
4.1 Roles and Services
Roles. There are three groups of users on the Fragments platform. Developers,
who develop and distribute micro-task apps and can take a commission on tasks
that are completed through their apps. Requesters, who need to have some tasks
completed and run a Task Repository from a particular micro-task app (either 3rd
party where commission might apply, or their own developed by themselves).