Search…
What are Audits?
Staying safe with decentralized and anonymous microservice providers.
In a decentralized system, it's important not to 'trust' any particular party. This not only ensures stability, but also increases transparency within the system by sharing the burden of truth broadly across the community.

Basics

How do audits work?
Any time that a task payload is submitted by a participating node, an audit can be called by any other node which has a stake in that task. During an audit, any participating nodes will automatically check the work of the suspect node, and vote to slash their stake if a majority of participating nodes agree that the submitted payload does not match the expected result. In practice, this means tasks can function as deterministic smart contracts, while also incorporating off-chain information and providing scalable integrations with storage-layer data.
What happens to the stake, when slashed?
If an audit vote is successful, a portion (up to 100%) of the misbehaving node's stake is distributed to all nodes who participated in the audit vote, with a larger portion typically being rewarded to the node which initiated the audit.
The Role of Witness Nodes
In addition to Task Nodes, which provide microservices and execute the task directly, witness nodes can also be incentivized to secure any task by designing an audit function that redistributes staked rewards to witnesses who vote during the audit. For most tasks, there exists a significantly less computationally expensive process that can be used to verify the results, which means that even a smart phone or personal device can earn reasonable rewards by auditing more hardware-heavy task nodes.

Writing Good Audits

The Audit Function
A Task is not complete without an Audit Function. This simple JavaScript executable may query Nodes operating the specific Task Executable and test their responses via the built-in REST API, or verify on-chain transactions match an intended flow, such as in bridge vault controls.
Writing Good Audits
Typically the main limitation of audits is repetition and sample size, but luckily Koii's nodes provide lots of participants to solve these issues. Despite this, when designing a task there are some key points to keep in mind:
  • Audits should always have deterministic outcomes
  • Ensure health checks exist for REST Endpoints
  • Penalties should be greater for clearly malicious behaviour than accidental downtime
  • Audit and task functionality can be separated into multiple tasks, if necessary
  • Staking requirements should not be overly large relative to bounties
  • Reputation over time and secondary tokens or NFTs can be used to permission task access
Economics & Risks
For many applications, especially community iniatives such as content collectives, there may be enough participating users to provide all of the necessary hosting without undue costs. Under these circumstances, KOII collected from attention can be centrally pooled into community Task Contracts, ensuring a perpetual stream of tokens to cover bounty costs. In these cases, it may not be necessary to require overly significant stake in KOII, and task creators may opt to instead require NFT ownership or secondary conditions such as an address whitelist to permission task operation, and audits may be less necessary since trust exists based on historical contributions instead of financial risk.
Note: Unfortunately, there is always the risk that a previously honest participant may have their personal devices compromised without their knowledge, so it is always a good practice to implement additional safeguards beyond simply permissioning access.
​
Copy link