Axel Cortes Cubero
    • Create new note
    • Create a note from template
      • Sharing URL Link copied
      • /edit
      • View mode
        • Edit mode
        • View mode
        • Book mode
        • Slide mode
        Edit mode View mode Book mode Slide mode
      • Customize slides
      • Note Permission
      • Read
        • Only me
        • Signed-in users
        • Everyone
        Only me Signed-in users Everyone
      • Write
        • Only me
        • Signed-in users
        • Everyone
        Only me Signed-in users Everyone
      • Engagement control Commenting, Suggest edit, Emoji Reply
      • Invitee
      • No invitee
    • Publish Note

      Publish Note

      Everyone on the web can find and read all notes of this public team.
      Once published, notes can be searched and viewed by anyone online.
      See published notes
      Please check the box to agree to the Community Guidelines.
    • Commenting
      Permission
      Disabled Forbidden Owners Signed-in users Everyone
    • Enable
    • Permission
      • Forbidden
      • Owners
      • Signed-in users
      • Everyone
    • Suggest edit
      Permission
      Disabled Forbidden Owners Signed-in users Everyone
    • Enable
    • Permission
      • Forbidden
      • Owners
      • Signed-in users
    • Emoji Reply
    • Enable
    • Versions and GitHub Sync
    • Note settings
    • Engagement control
    • Transfer ownership
    • Delete this note
    • Save as template
    • Insert from template
    • Import from
      • Dropbox
      • Google Drive
      • Gist
      • Clipboard
    • Export to
      • Dropbox
      • Google Drive
      • Gist
    • Download
      • Markdown
      • HTML
      • Raw HTML
Menu Note settings Sharing URL Create Help
Create Create new note Create a note from template
Menu
Options
Versions and GitHub Sync Engagement control Transfer ownership Delete this note
Import from
Dropbox Google Drive Gist Clipboard
Export to
Dropbox Google Drive Gist
Download
Markdown HTML Raw HTML
Back
Sharing URL Link copied
/edit
View mode
  • Edit mode
  • View mode
  • Book mode
  • Slide mode
Edit mode View mode Book mode Slide mode
Customize slides
Note Permission
Read
Only me
  • Only me
  • Signed-in users
  • Everyone
Only me Signed-in users Everyone
Write
Only me
  • Only me
  • Signed-in users
  • Everyone
Only me Signed-in users Everyone
Engagement control Commenting, Suggest edit, Emoji Reply
Invitee
No invitee
Publish Note

Publish Note

Everyone on the web can find and read all notes of this public team.
Once published, notes can be searched and viewed by anyone online.
See published notes
Please check the box to agree to the Community Guidelines.
Engagement control
Commenting
Permission
Disabled Forbidden Owners Signed-in users Everyone
Enable
Permission
  • Forbidden
  • Owners
  • Signed-in users
  • Everyone
Suggest edit
Permission
Disabled Forbidden Owners Signed-in users Everyone
Enable
Permission
  • Forbidden
  • Owners
  • Signed-in users
Emoji Reply
Enable
Import from Dropbox Google Drive Gist Clipboard
   owned this note    owned this note      
Published Linked with GitHub
1
Subscribed
  • Any changes
    Be notified of any changes
  • Mention me
    Be notified of mention me
  • Unsubscribe
Subscribe
# Extracting truth in the Checker Network The Spark network has been incredibly successful in providing data retrieval metrics for Filecoin, which are being used to incentivize higher retrieval success rates (cite some stuff). As the Spark network (and the more general Checker network) scales , and stakes become higher, there are clear challenges in incentive alignment. The core issue is that Spark retrievability scores rely on honest reporting from a set of checkers. Space Meridian and CryptoEconLab are teaming up to re-work Checker incentives from the ground up, focusing on incentivizing truthful reporting. ## Spark basic mechanics While Filecoin's Proof of Space-time guarantees that a storage provider (SP) is storing a specific piece of data, the protocol does not provide guarantees to the user that they will be able to retrieve the given file. Spark protocol enhances Filecoin by assigning SP's a retrievability score, which informs how likely one is to obtain the file from the SP upon request. Spark works by randomly assigning a set of "checkers" to attempt to retrieve a particular piece of data from Filecoin. These checekers then report to the Spark protocol whether they received the file or not. These reports are then used to build the retrievability score for the SP. ## The problem with the Checker model The dynamics we have just described produce a desirable outcome (of providing an accurate retrievability score) only with the assumption that all checeker nodes are acting honestly, as well as the assumption that the SP's cannot single out checker nodes and serve retrievals only to them. Once external incentives start weighing in, this honesty assumption starts becoming less reliable. These external influences include for example: * Cost of checking. It is cheaper for the checker to not try to retrieve the file, and simply providing a response without actually checking. * Collusion: As having a high retrievability score provides higher value for the SP, these can collude with checkers to improve their scores. More problems may emerge as a more general Checker network is built, and there may be more complex checker-service provider interactions. ## Checker network innovation: Incentivizing truth To address this issues, the Checker protocol is being reworked from the ground up, and built around the new paradigm of incentivizing truth. In an ideal world, we would have cryptographic proofs available for any kind of activity the Checker network is checking, such that checkers cannot lie. Unfortunately such proofs of retrievability of a file do not exist as they do for storing a file. This problem is wider than just the data retrievability problem, as in general no such proofs for "fair exchange" problems are available. In the lack of cryptographic proof, we focus on economic incentivization of truthful checking. We mainly aim to acheive two goals: 1) for it to be economically favorable for a checker to report with the truth (which prevents misalignment from rational checkers), and 2) Dishonest reporting is detectable and penalizable (which would discourage malicious checkers). We will briefly go over two of the core ideas that power the protocol, which address the two goals above: The **Ising model checker game** (we can work on a name), and the **Checker repututation algorithm**. ### Ising model Checker game Let us define the preamble for the Ising model Checker game (IMCG). In a given round, a set of $N$ checkers are randomly assigned by the protocol to attempt to retrieve a specific piece of data. Each checker requests the data from the SP, and either successfully retrieves it or not. Each Checker must then report to the Spark protocol, whether they successfuly retrieved the file or not. That is, each checker, labeled as checker $i$, returns an binary answer, $\sigma_i=-1,1$, with a value of $1$ if the file was retrieved and $-1$ if it wasn't The question is then, how do we encourage the answer $\sigma_i$ from each checeker to actually be truthful? #### Simplified case: no external information Suppose all checkers have no external information on the piece of data they are retrieving or the SP storing it. That is, they have no a priori opinion on whether this file is likely to be retrievable or not. In this scenario truthful reporting can be incentivized by rewarding checkers that are more aligned with other checkers. For example, we can propose a reward for checker $i$ of the form, $$R_i=\frac{J}{N}\sum_{j=1}^N \sigma_i\sigma_j.$$ Checker $i$ can then obtain higer rewards by ensuring their vote is aligned with the majority of other checkers. The higher this parameter $J$ the stronger the incentive for alignment of votes. **In the absence of any external information, the best strategy for a checker to try to reach alignment, is to report truthfully**. To maximize their reward, checker $i$ has to guess which outcome (-1 or +1) will be most likely, so they would try to align with it. Their only piece of information available to make this guess, is the true outcome of their retrieval request. A reader familiar with the physics of magnetism, would notice that this reward function takes the shape of the total energy function of the *Infinite range Ising model*, where this interaction encourages the alignment of atomic spins, and if the interaciton is strong enough, lead to magnetization (or alignment of spins). #### External information: Previous retrieval score The above incentives are spoiled if the checker has any information on whether the SP is more or less likely to provide the file when requested. For example, and SP may have an existing retrievability score that the checkers have access to. For instance, if the SP has an existing retrievability score of 90%, then the checker knows alignment is more likely to happen in the direction of $\sigma_i=+1$. In this case, even if they were not able to successfully retrieve the file, they may choose to dishonestly say they did, to increase the chances of alignment. This influence from the previous retrievability score can be countered by introducing an *external magnetic field* $$R_i=\frac{J}{N}\sum_{j=1}^N \sigma_i\sigma_j+h\sigma _i.$$ This "magnetic field" term explicitly breaks the symmetry of the reward, giving higher reward if alignment happens in the direction of $h$. For any previous retrieval history for a given SP, the Checker protocol's algorithm is able to calculate a specific magnetic field term, that directly cancels the influence of the retrieval history. This restores, even in the presence of a previous score, the strategy of checkers reporting truthfully as the way to maximize their reward. The mathematical details of this algorithm, relying on an application of the statistical mechanics of the infinite range Ising model, will be published soon in a full length paper. ## Checker reputation algorithm The Ising model Checker game ensures that at each individual round, the optimal strategy for each checker is to try to reach alignment with other checkers by responding truthfully. The incentives of rational checkers are thus aligned with the network's goals. This, however leaves open the question of malicious checkers, which have external motivations for falsifying their reports. The Checker Reputation algorithm is there to detect whether any checker consistently acts "irrationally", so their impact on reported metrics can be minimized. Each checker will be assigned a reputation score, which is based on several critical factors, including in particular: * Likely truthfulness over time * Entropy contrast Having this reputation score allows us to tune the rewards that a checker node receives, and so can be used to penalize malicious nodes by taking their rewards. Identifying disreputable nodes also allows us to treat their reports as less trustworthy, and reduce the impact they have on an SP retrievability score, for instance. #### Likely truthfulness Suppose $N$ checkers are asked to retrieve a file from an SP in a given round, and 70% of checkers report having received the file. There are still 30% of checkers with the "unlikely" answer of not having received the file. Are those checkers minority lying? This is impossible to know in one round, it could very well be that the checker recevied the file but decided to lie, or that they did not receive the file. The key insight of the likely truthfulness component, is that while it is impossible to know in one particular round if a checker lied about their result, as they build a voting record over time, it is possible to build a stronger idea of whether the checker has been voting truthfully. Suppose the experiment we have described is repeated 1000 times. It would be increasingly unlikely for an honest checker to be always in the minority of the vote, 1000 times in a row. It is in fact possible to compute the likelihood that the checker's voting record arises from honest reporting. As the checker builds a voting record, they build a likely truhfulness score, which can be used to steer network incentives. A checker who is unlikely to have been voting truthfully, will be able to receive fewer rewards, and will have less impact on an SP's retrievability score. #### Entropy contrast While the likely truthfulness compares the checker's voting record with the actual resulting votes from each round, the Energy contrast metric compares the voting record with itself to determine a likelihood of the record arising honestly. The voting record of a checker that is reporting honestly will have a natural level of "noise". That is, sometimes the vote will be "yes" and sometimes "no", with a certain level of disorder, that can be measured. [Entropy](https://hackmd.io/o6okWKOTTryDGSqFO_fK5w?both=&stext=9480%3A7%3A0%3A1738177301%3A_gq9Sm) is a well established measure which can be applied to measure this type of disorder, or apparent "randomness" in an honest checker's record. A checker that is "lazy", in the extreme case, could always vote "no". This would lead to at least some of the time, the checker agreeing with the majority vote, so the likely truthfulness from the previous section would not be the best measure of "laziness". A voting record of all "no's" would however have an easily detectable low entropy score. Conversely, an entropy score that is very large can signal that the checker is simply voting randomly. More generally, we can compute the entropy of a checker's voting record, and contrast it with a typical expected entropy of an honest checker. Large entropy contrast can signal either laziness, or other dishonest voting strategies. ## Stacking incentives on top of truth These truthful game form the fundamental building blocks of the Checker protocol economics. These building blocks will be superpowered when coupled to Checker tokenomics. Having powerful truth-incentivizing protocols allow the Checker token to be deployed in an efficient and impactful matter, and to swiftly cutoff when dishonesty is detected. This will lead to lean tokenomics where no token emissions are "wasted" and any meaningless inflation can be avoided. Stay tuned for our full tokenomics white paper coming soon!

Import from clipboard

Advanced permission required

Your current role can only read. Ask the system administrator to acquire write and comment permission.

This team is disabled

Sorry, this team is disabled. You can't edit this note.

This note is locked

Sorry, only owner can edit this note.

Reach the limit

Sorry, you've reached the max length this note can be.
Please reduce the content or divide it to more notes, thank you!

Import from Gist

Import from Snippet

or

Export to Snippet

Are you sure?

Do you really want to delete this note?
All users will lose their connection.

Create a note from template

Create a note from template

Oops...
This template is not available.
Upgrade
All
  • All
  • Team
No template found.

Create custom template

Upgrade

Delete template

Do you really want to delete this template?
Turn this template into a regular note and keep its content, versions, and comments.

This page need refresh

You have an incompatible client version.
Refresh to update.
New version available!
See releases notes here
Refresh to enjoy new features.
Your user state has changed.
Refresh to load new user state.

Sign in

Forgot password

or

By clicking below, you agree to our terms of service.

Sign in via Facebook Sign in via Twitter Sign in via GitHub Sign in via Dropbox Sign in with Wallet
Wallet ( )
Connect another wallet

New to HackMD? Sign up

Help

  • English
  • 中文
  • Français
  • Deutsch
  • 日本語
  • Español
  • Català
  • Ελληνικά
  • Português
  • italiano
  • Türkçe
  • Русский
  • Nederlands
  • hrvatski jezik
  • język polski
  • Українська
  • हिन्दी
  • svenska
  • Esperanto
  • dansk

Documents

Help & Tutorial

How to use Book mode

How to use Slide mode

API Docs

Edit in VSCode

Install browser extension

Get in Touch

Feedback

Discord

Send us email

Resources

Releases

Pricing

Blog

Policy

Terms

Privacy

Cheatsheet

Syntax Example Reference
# Header Header 基本排版
- Unordered List
  • Unordered List
1. Ordered List
  1. Ordered List
- [ ] Todo List
  • Todo List
> Blockquote
Blockquote
**Bold font** Bold font
*Italics font* Italics font
~~Strikethrough~~ Strikethrough
19^th^ 19th
H~2~O H2O
++Inserted text++ Inserted text
==Marked text== Marked text
[link text](https:// "title") Link
![image alt](https:// "title") Image
`Code` Code 在筆記中貼入程式碼
```javascript
var i = 0;
```
var i = 0;
:smile: :smile: Emoji list
{%youtube youtube_id %} Externals
$L^aT_eX$ LaTeX
:::info
This is a alert area.
:::

This is a alert area.

Versions and GitHub Sync
Upgrade to Prime Plan

  • Edit version name
  • Delete

revision author avatar     named on  

More Less

No updates to save
Compare
    Choose a version
    No search result
    Version not found
Sign in to link this note to GitHub
Learn more
This note is not linked with GitHub
 

Feedback

Submission failed, please try again

Thanks for your support.

On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?

Please give us some advice and help us improve HackMD.

 

Thanks for your feedback

Remove version name

Do you want to remove this version name and description?

Transfer ownership

Transfer to
    Warning: is a public team. If you transfer note to this team, everyone on the web can find and read this note.

      Link with GitHub

      Please authorize HackMD on GitHub
      • Please sign in to GitHub and install the HackMD app on your GitHub repo.
      • HackMD links with GitHub through a GitHub App. You can choose which repo to install our App.
      Learn more  Sign in to GitHub

      Push the note to GitHub Push to GitHub Pull a file from GitHub

        Authorize again
       

      Choose which file to push to

      Select repo
      Refresh Authorize more repos
      Select branch
      Select file
      Select branch
      Choose version(s) to push
      • Save a new version and push
      • Choose from existing versions
      Include title and tags
      Available push count

      Upgrade

      Pull from GitHub

       
      File from GitHub
      File from HackMD

      GitHub Link Settings

      File linked

      Linked by
      File path
      Last synced branch
      Available push count

      Upgrade

      Danger Zone

      Unlink
      You will no longer receive notification when GitHub file changes after unlink.

      Syncing

      Push failed

      Push successfully