Comment on page
Architectural Motivations
Many advantages today: allows “open books” to prove the system is fairly distributing bounties, enables efficient micro-payments, reduces required trust between protocol actors.
Even more advantages when blockchains are faster: verifiable reputation for every actor that opts in, oracle can compute earnings on-chain to further reduce required trust for interactions.
Ethereum has the most robust smart contract support of any popular blockchain, but without additional development it is too slow and expensive for many applications.
Our HUMAN Token (HMT) contract thus implements a custom Bulk API that supports efficient micropayments via one-to-many bulk transfers. In other words, a single call can specify payouts from a smart bounty to 1000 addresses. This enables new and interesting use cases while remaining EIP20-compatible. We have open sourced the audited contract with a library and comprehensive test suite to help other projects in the wider Ethereum developer community adopt this approach as it suits their needs.
Current systems: no blockchain, centralized authority, REST API. No compensation for use.
Challenge: no blockchain today has adequate performance for use as a full-scale distributed human review system. Plasma, Lightning, Hashgraph, etc are still orders of magnitude away from necessary cost/speed performance and not yet robust. Future improvements may eventually make this feasible, but still early days.
Hybrid model thus ideal: faster to build, easier to scale using robust, proven strategies. Blockchain is used primarily for settlement, rather than trying to put every bit of logic into an on-chain oracle and every bit of data directly on-chain.
Start more centralized, cheap and deterministic. Build in ability to decentralize each component as tech evolves.
What do we want on the blockchain?
Immediately:
• Smart bounties: requester puts HMTs in escrow, describes their order, sets price.
• Immutable hash, location (URI) of intermediate & final data, reputation results per job.
Eventually:
• Mining server trust scores.
• Requester trust scores.
• Neither one required for MVP. Can start with rolling reputation computation for graylists at the exchange level and mandatory request signing by reputation agent.
What do we NOT want on the blockchain?
• Data: images, texts, etc comprising datasets.
• Individual responses from mining clients: can be millions for a single job.
• Side chains (Plasma etc) not ready for primetime, unfortunately. - REST API services.
• Mining client needs a location to hit, get go/no go response.
Example App Overview Diagram (Simplified)
An overview of the data path for hCaptcha.com, an application built on HUMAN Protocol.
Last modified 10mo ago