Data is the most valuable asset companies have. There are strict requirements about who can access the data and this means they must establish binding agreements with the workers. Given the nature of Fragments’ platform, we have designed our agreements to comply with these needs, especially for companies who currently use in-house employees and are considering migrating and outsourcing their tasks to scale better.
Agreements will be created by requesters (companies). Workers will have to sign them in order to be able to work on more sensitive tasks. One of the most prominent examples of an agreement is an NDA (non-disclosure agreement). Other agreements might include proof of passing tutorials, where workers will pass competency tests before beginning the actual work on micro-tasks.
These agreements are crucial for data protection and quality management, so they must be binding. This is why we implement them on the blockchain to facilitate trust, binding an agreement to a worker’s ethereum address, which will in turn be connected to the worker’s identity using blockchain ID services. This system (in combination with a blacklist) will ensure that those who violate any agreement will not be able to participate in the platform any more.
This is a proof-of-concept approach, where we demonstrate the way we want to tackle this problem — we aim to minimize the gas costs for agreements and investigate other options, such as companies who might cover these costs. We are open-sourcing our demo on GitHub and are keen to receive community feedback.
Two sides of the agreement
What will both parties usually need to agree on? At Fragments, we divide agreements into three distinct components:
The first component is the informative documents which are shared. These will usually contain information about the requester, the purpose of the tasks, and any other general information or requirements. You can imagine this component as the body of a real-world legal contract. (Metadata, such as identity of parties involved, will be handled by other components and/or by Ethereum itself.)
The second component we call ‘conditional validity’. Here, you can specify things such as expiration terms of the agreement, or any other logic needed for the micro-tasks. In situations where you don’t need additional conditions, you can use a dummy (unconditional) component instead.
The third and final component is the logic needed for the agreement signing itself. Above all else, it is important to note that signing of the agreement will be realized as Ethereum’s transaction to the agreement smart contract.
Use cases
Let’s illustrate some non-obvious situations that we aim to support with our modular architecture.
In a situation where many workers are expected, we aim to limit Ethereum gas consumption for contract deployment(s). Requesters can create a single “asymmetric” agreement that can be signed by multiple workers (instead of having a separate agreement with each of the workers). In this case we want to be able to check that the treaty is valid for each worker independently.
Another example could be multi-step signing. Imagine a semi-private task repository aimed at image classification of very rare herbs that can be reliably classified only by postgraduate students of biology. In such a case, the chosen universities could be required to co-sign the agreement between requester and worker to verify the worker’s proficiency.
One last example of signing logic could be an agreement which is signed only when passed through a blacklist or whitelist.
Task requester’s point of view
Let’s take a look at the steps a requester will need to carry out in order to create an agreement.
In Fragments, we will provide many templates for Ethereum contracts that can be composed into an agreement. Task requesters will need to decide on (or discuss) requirements for an agreement and then select from the provided templates, or write a new Solidity contract that fulfills the needs of the generic agreement’s interface. Besides contract templates, we will also provide the user interface for generating an agreement. A prototype of this interface can be seen in the following video:
As you can see, the user interface can be pretty simple for a generic agreement (or an agreement that somebody created and shared the source code for). Using this interface, the task requester can easily select the desired features of the agreement and later deploy the agreement to the Ethereum network.
In the same way the Fragments team will provide templates for agreement features, it will also provide templates for complete agreements that are used most often, and can be quickly adopted using a one-click deployment process. The Ethereum gas price of deployment will depend on the complexity of the final contract, though we focus on minimizing the gas consumption both on contract deployment and in its usage.
Deployed agreements will have three key callable functions (more functions may be added to the contract via the agreement parts described above):
- Anybody on the Ethereum network can ask the deployed contract if it is completely valid. This will usually check if all parties that should sign the agreement did so, and that the agreement hasn’t expired (as well as other conditions).
- Especially in the case of asymmetric signing (an agreement that can be signed by an unlimited number of workers), requesters will need to check if one certain worker (represented by Ethereum address) signed the agreement, and that it’s valid for them in particular.
- The last key function will be for the worker to sign the agreement.
Worker’s point of view
When a worker comes into play, the agreement’s contract is already deployed. Because of this, the worker only needs to carry out two principal actions. Firstly, they must read the agreement’s documents and any extra validity conditions (e.g. the agreement’s expiration). Everything can be read from the Ethereum blockchain but regular users will interact via a user-friendly interface that hides all blockchain interaction from them, as can be seen in the following image displaying our prototype interface for workers.
Once the worker is fully acquainted with the agreement, he can sign it by simply clicking on a button and confirming the Ethereum transaction.
Advanced possibilities
The agreement contract is defined by an interface. This interface requires implementation of only two functions (checking if the agreement is signed and valid). For better modularity, we have our reference implementation of a contract divided into several parts, as described in previous sections.
For each part of the agreements, we have created at least two reference implementations to demonstrate various possibilities as to how they can be composed. For more information about implementation, please visit our github.
In the following animation you can see the whole procedure of creating and then signing an agreement, involving two different parties.
Join the Fragments movement
We need you, our community, to help us achieve our global ambitions. With your help we can bring Fragments to life and create the workforce of the future.
Join Community on Telegram: https://t.me/fragments
See our website: https://fragments.network
Follow us on Twitter: https://twitter.com/fragment
Fork us on GitHub https://github.com/FragmentsNetwork
— Ondřej Raška — blockchain dev @ Fragments team
