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
    • Invite by email
      Invitee

      This note has no invitees

    • Publish Note

      Share your work with the world Congratulations! 🎉 Your note is out in the world Publish Note

      Your note will be visible on your profile and discoverable by anyone.
      Your note is now live.
      This note is visible on your profile and discoverable online.
      Everyone on the web can find and read all notes of this public team.
      See published notes
      Unpublish note
      Please check the box to agree to the Community Guidelines.
      View profile
    • 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
    • Note Insights
    • 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 Versions and GitHub Sync Note Insights Sharing URL Create Help
Create Create new note Create a note from template
Menu
Options
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
  • Invite by email
    Invitee

    This note has no invitees

  • Publish Note

    Share your work with the world Congratulations! 🎉 Your note is out in the world Publish Note

    Your note will be visible on your profile and discoverable by anyone.
    Your note is now live.
    This note is visible on your profile and discoverable online.
    Everyone on the web can find and read all notes of this public team.
    See published notes
    Unpublish note
    Please check the box to agree to the Community Guidelines.
    View profile
    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

    Paste your markdown or webpage here...

    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 has been removed or transferred.
    Upgrade
    All
    • All
    • Team
    No template.

    Create a 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

    Slide Example

    API Docs

    Edit in VSCode

    Install browser extension

    Contacts

    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
    Get Full History Access

    • Edit version name
    • Delete

    revision author avatar     named on  

    More Less

    Note content is identical to the latest version.
    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

        Pull from GitHub

         
        File from GitHub
        File from HackMD

        GitHub Link Settings

        File linked

        Linked by
        File path
        Last synced branch
        Available push count

        Danger Zone

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

        Syncing

        Push failed

        Push successfully