search

pobstudio / HCIPs

Formalized conversation around $HASH community improvement proposals
https://pob.studio/
Apache License 2.0
2 stars 0 forks source link

Create metadata claim verification process #2

Open vrortvedt opened 3 years ago

vrortvedt commented 3 years ago

Summary

Owner-written annotations are an excellent way to communicate what a HASH TX represents, including its historical significance.

But incorrect or misleading annotations could induce unsophisticated HASH buyers to trust the claim without verifying it and overpay based on the falsehood. This would hurt the project's reputation, especially because user annotations show up as HASH titles and descriptions on OpenSea and may be mistaken for claims made by the project itself.

What is proposed is a minimally-functional, opt-in verification system with loud signaling as to unverified claims to protect buyers and the project's reputation. It would allow owners to request claim verification, appoint a group of identified individuals to act as historians to research and verify the claims, and add a "Verified" property to the claim's metadata.

Motivation

The HASH project is a wonderful way to curate and tell the story of Ethereum using generative art visuals minted from unique transaction hashes. Adding explanatory titles and descriptive annotations can massively increase the viewer's comprehension of the significance of the TX underlying the art, plus it allows owners to add their personal voice to the context surrounding these unique pieces.

Currently nothing prevents owners from making whatever representations they wish about their HASHes. Misleading or inaccurate titles and descriptions look just the same as accurate ones, and it is left to the viewer to independently verify whether the claim is true. This undercuts the value of the annotations.

Buyers could be misled into overpaying for a HASH by the belief that it is more historically significant or rare than it is. Any owner - either through innocent mistake or willful deceit - may claim that a HASH is the first TX ever made on Ethereum, but that is only true of one HASH.

We have already seen instances of misleading or inaccurate or misleading historical claims in HASH annotations, prompting the need for this HCIP. See https://discord.com/channels/797978413691305995/813437883238973520/814506298246561812 and https://discord.com/channels/797978413691305995/813437883238973520/815264847171289109

It's also important to recognize that many fans of POB HASHes may not be familiar with reading and understanding TX hash data as it's displayed on explorers like Etherscan, and so are incapable of verifying whether a claim is true. More probable is that HASH viewers will either tend to believe all annotations are probably true and risk getting fleeced, or to assume they are all most likely inaccurate and disregard the project in general. Neither is good for the viability of the project.

In order to protect buyers and the reputation of the project as a serious historical indexing endeavor, we should create a minimally viable claim verification system.

We don't want to sacrifice decentralization and permissionlessness by inserting a centralized gatekeeper who is tasked with approving every submitted annotation. A lightweight verification system might have the following components:

It is proposed to create the first iteration of the historians panel by seeking volunteers to serve on a 3 of 5 multisig. The panel would also be responsible for publishing guidelines for annotations containing historical claims so that owners seeking verification can know how to frame their claims.

Rationale

Eventually a historians DAO may be the best long term solution for this challenge.

But given the early experimental stage of the HASH project, it makes more sense to get a minimally viable cohort working on this issue before the problem grows unwieldy and causes harm. It is expected that a fair amount will be learned about how best to accomplish this task in the doing of it, knowledge which will benefit the proper construction of a future DAO.

A small, nimble team working transparently should be able to bring efficient results and help lay the foundation for the work of the permanent body.

Implementation

There are three pieces to implementing this proposal:

  1. Recruit and approve the initial historians panel and set the scope of their work
  2. Modify the smart contracts to include "verified" metadata and permitting the panel to make those determinations - a function allowing multiple HASHes to be set to verified in a single TX is preferred
  3. Update the UI to display the verification status and allow owners to request that their claims be submitted for verification

Designated team

Open and up for grabs. Anyone interested in serving on the historians panel should indicate their interest by responding to this issue below, including the following information:

Name: Discord handle: Background in the space: On-chain research competency:

Sponsor

None at the moment

Notes

Here's an in-progress spreadsheet detailing and describing the hacks and exploits represented by some of the minted HASHes - it's semi-related to the type of work the panel historians would be doing: https://docs.google.com/spreadsheets/d/1j9nXjENVsHEaHCBzZ1bNsMZ7-7WSoYkkvU-adr5h5Ks/edit#gid=2111404613

vrortvedt commented 3 years ago

I'm interested in serving on the historians panel.

Name: Victor Rortvedt Discord handle: @victorrortvedt#3874 Background in the space: Full time in the space since 2018 (prior life as litigation attorney and Ethereum lurker); Solidity; Builder with rDAI and Spendless, Blood Mage in MetaCartel Ventures DAO On-chain research competency: Can write Solidity; fluent in Etherscan; avid consumer of Ethereum technical media, including hack breakdowns; familiar with major attack and exploit vectors; not unskilled in the degen arts

ensingerphilipp commented 3 years ago

Very interested in serving on the historians panel too!

Name: Philipp Ensinger Discord Handle: @ herodotus#2018 Background in the Space: Following crypto since 2015 and actively investing since 2016. Very interested in taking my first steps here to get involved with a project more than just investing. On-Chain research competency: Fluent in Etherscan and google BigQuery (public ethereum dataset); working on a ethereum transaction flow tracker as a university project; currently in the process of learning solidity with focus on security auditing; DeFi & NFT as part of the daily routine.

dave4506 commented 3 years ago

This is awesome and super excited to see this going.

To this, I want to speak on how pob.studio will play into this and also give some light as to how this can be implemented.

I will leave it to @vrortvedt to setting up some multi-sig or address that should have the right submit to this metadata contract claims.

On the protocol level; we will need to deploy a new contract that contains these claims. The current token-metadata contract is designed for personal annotations and has been designed with no backdoor. This new contract will be controlled by this collection/DAO/organization and can retain the capacity to govern it in the future. This new contract can be a fork of the current token-metadata contract. POB studios will take on deploying such a contract.

On the UI level we will surface it on pob.studio and on opensea, (how that would be 'shown' is a matter of conversation still)

Some of the open questions on my mind:

Feel like getting this group of interested parties together on discord is a good first step to iron out some of the details.

ensingerphilipp commented 3 years ago

@dave4506 Regarding question 1: Do you mean discussions about general proposals or discussions about history proofs?

Either way imo it should be done in a public and visible way maybe via a governance forum like other defi platforms use: e.g.: https://gov.yearn.finance/ There could be a section for proposals and a section for discussion about history proofs. As long the system is not fully decentralized all reasoning for verifying a specific tx should be visible there to help improve trust in the system. Depending on the model of decentralization chosen later, this section could still be open for discussions about transaction but may not be as important anymore.

Regarding question 4: To bootstrap the first historians I think it is reasonable to have them appointed by the POB studios team having in mind a transition to full decentralization as soon as possible. Some restrictions on who can be one of the first historians could be for example:

(these are just examples, maybe you guys have better ideas)

Song1990CN commented 3 years ago

Name: Song Guo Discord handle: @Song #1990 Background in the space: NFT Asset manager and curator for a partnership focus on NFT. Main area: ENS, Metaverse and Crypto Art, Gen Art (Expert level understanding of the market and customer). NFT OG and involved in multiple NFT related marketplace and projects. On-chain research competency: Fluent in Etherscan; can use dune for some detailed analysis, expert level understanding of things happened in ENS, Metaverse and Crypto Art fields.

vrortvedt commented 3 years ago

To this, I want to speak on how pob.studio will play into this and also give some light as to how this can be implemented.

I will leave it to @vrortvedt to setting up some multi-sig or address that should have the right submit to this metadata contract claims.

Happy to set up a Gnosis Safe once we have a core crew of volunteers.

On the protocol level; we will need to deploy a new contract that contains these claims. The current token-metadata contract is designed for personal annotations and has been designed with no backdoor. This new contract will be controlled by this collection/DAO/organization and can retain the capacity to govern it in the future. This new contract can be a fork of the current token-metadata contract. POB studios will take on deploying such a contract.

On the UI level we will surface it on pob.studio and on opensea, (how that would be 'shown' is a matter of conversation still)

Awesome - thanks POB team!

Some of the open questions on my mind:

  • where are these discussions taking place?

I envision three venues for discussion:

  1. Private historians channel for panel members to discuss claims
  2. Public historians channel for publicizing verification decisions and explaining policies
  3. Spreadsheet or other data management tool for historians to track progress on submitted claims I'm thinking each panelist would be assigned as first reviewer for a portion of the submitted claims and he/she would then research the TX and supporting materials and make an initial verdict in a particular field, explaining the rationale and linking to relevant URLs. Then the remaining panelists would review the initial verdict and co-sign if they agreed with the decision. First reviewers would also be able to escalate a particular claim if they have trouble making a clear verdict.

  • what kind of governance process is happening? will a quorum be required? I think we should seek consensus from all panelists in order to verify a claim. Verification should be treated seriously as we'll be telling the secondary market they can rely on our judgment - being wrong even once could injure the project's reputation. "Pretty sure this is right" won't cut it. Each panelist should have veto power over a claim being verified while we are starting out. Worst case scenario is that owners and the community thinks our standards are too high, perhaps incentivizing them to gather better evidence.

  • how does this current design transition to a more decentralized design? I think we should be planning for a DAO to take over the verification process as soon as it is viable, but believe this conversation should involve David and the core team, as their views on incentives and tokenomics will heavily influence the design.

  • how are the first panel of historians chosen + how will net new historians be chosen. For this initial proposal, we should consider the applications of individuals who post here, with David and team having the final say.

I think we shouldn't add any new historians unless they offer a skill that's missing from the panel. New historians should plan to join the DAO.

Feel like getting this group of interested parties together on discord is a good first step to iron out some of the details.

Perhaps you could create an invite-only discord channel where we could hammer these details out?

vrortvedt commented 3 years ago

Here is a proposed Claim Verification Process - please review and comment in the doc: https://hackmd.io/T253xfyEQI6xYGXxWdkPVw

dave4506 commented 3 years ago

^ on that:

I like the specificity and the high level process of verifying.

Speaking more on getting this going:

  1. Let's get a airtable form going that people can submit reviews to. We will link it on the pob.studio site. (@vrortvedt + @ensingerphilipp can this be owned by the two of you?)
  2. A public historians-only discourse channel to publicly evaluate these claims (We can create this)
  3. A bot to share verified claims (Can anybody own this?, if not we keep this manual)
  4. A contract to contain these claims. What do you think needs to be submitted? (Forking this contract and granting write access to an address of the historians choosing)
  5. UI + metadata updating (POB studios will do this)
  6. A process discoursing, verifying claims (@vrortvedt document highlights this very well and seem the place we can start off)

What you have @vrortvedt is awesome, only thing I would say we cut a corner now is just using a standard form to collect claims until dev resources free up for something more bespoke. If we have spams + sybil resistance issues, we will look into something requiring owner's signing something.

Hopefully, if time permitting, I'll get to this protocol + metadata + UI updating this week or early next week. I'll leave some of the other processes to the other interested parties and help out where needed.

vrortvedt commented 3 years ago

Great plan - totally agree we should start lean and fast and work in the open to generate community buy-in. I'm working on setting up an airtable now.

ensingerphilipp commented 3 years ago

Great plan! @dave4506 On the Bot to share verified claims - i could probably do that depending on what exactly it is you want - could you detail a little further what you were thinking about?

@vrortvedt Haha youre always superfast at it 😁 if you need some help with airtable be sure to hit me up

dave4506 commented 3 years ago

@ensingerphilipp I am thinking of some bot that reacts to when a claim has been submitted on-chain as verified by the historians. (So it would probably be listening for a event)

ensingerphilipp commented 3 years ago

Sounds good, i can do that 👍

I am thinking about implementing a bot with python that uses a centralized Ethereum node service to get the on-chain data.

Some thoughts i have in mind:

Is the smart contract side of the historians panel already in the works? I will need to know what kind of interfaces in the smart contract i can expect, what data is available etc.

dave4506 commented 3 years ago

The bot for now, should just post into the channel when a verification has been mined and on-chain.

I don't believe there will be a manual interface (let's keep it simple). It should post the asset, the title + description, and the verification? Since the actual protocol hasn't been written yet, I'll need to come back to u on that @ensingerphilipp.

The bot really needs to do is listen for events (maybe there is a webhook service already like Matic's dagger or Alchemy's notify that can do this) and convert the events to readable messages to be sent to a discord webhook.

ensingerphilipp commented 3 years ago

Thanks! Sure i was actually thinking about using alchemy or infura 👌

dave4506 commented 3 years ago

We also now have a subgraph. They have a websocket connection that would allow listening.

When we have this new metadata registry figured out, I'll update the subgraph accordingly. @ensingerphilipp

dave4506 commented 3 years ago

This is my first draft of the new permissioned metadata writer.

The owner will be retained by POB studios for now until a DAO or some structure can exist.

writers are addresses that can write into the metadata.

With this, it is up to the historians to decide on the metadata needed to be submitted on-chain. (Mindful of the gas considerations)

Leave feedback on its design, and once we agree on something, I'll move this to testing, auditing and deploying live.

pragma solidity ^0.7.0;
pragma experimental ABIEncoderV2;

import "./lib/LibSafeMath.sol";
import "./ERC1155Mintable.sol";
import "./mixin/MixinOwnable.sol";
import "./mixin/MixinSignature.sol";

contract PermissionedTokenMetadataRegistry is Ownable, MixinSignature {
  using LibSafeMath for uint256;

  ERC1155Mintable public mintableErc1155;

  mapping(uint256 => mapping(string => Document)) public tokenIdToDocumentMap;
  mapping(address => bool) public permissedWriters;

    struct Document {
        address writer;
        string text;
        uint creationTime;
    }

  struct SignedText {
    address writer;
    string text;
    uint256 salt;
    bytes signature;
  }

  constructor(
    address _mintableErc1155
  ) {
    mintableErc1155 = ERC1155Mintable(_mintableErc1155);
  }

  event UpdatedDocument(
      uint256 indexed tokenId,
      address indexed writer,
      string indexed key,
      string text,
      uint256 salt,
      bytes signature
  );

  function getSignedTextHash(SignedText memory signedText) public pure returns(bytes32) {
      return keccak256(abi.encodePacked(signedText.writer, signedText.text, signedText.salt)) ;
  }

  function verifySignedDocument(SignedText memory signedText) public pure returns(bool) {
    bytes32 signedHash = getSignedTextHash(signedText);
    (bytes32 r, bytes32 s, uint8 v) = splitSignature(signedText.signature);
    return isSigned(signedText.writer, signedHash, v, r, s);
  }

  function updatePermissedWriterStatus(address _writer, bool status) public onlyOwner {
    permissedWriters[_writer] = status;
  }

  modifier onlyIfPermissed(address writer) {
    require(permissedWriters[writer] == true, "writer can't write to registry");
    _;
  }

  function writeAndVerifyDocuments(uint256 tokenId, string[] memory keys, SignedText[] memory signedTexts) public onlyIfPermissed(msg.sender) {
    require(keys.length == signedTexts.length, "tokenIds and txHashes size mismatch");
    for (uint256 i = 0; i < keys.length; ++i) {
      string memory key = keys[i];
      SignedText memory signedText = signedTexts[i];
      require(verifySignedDocument(signedText) == true, 'invalid signature');
      tokenIdToDocumentMap[tokenId][key] = Document(signedText.writer, signedText.text, block.timestamp);
      emit UpdatedDocument(tokenId, signedText.writer, key, signedText.text, signedText.salt, signedText.signature ); 
    }
  } 

  function writeDocuments(uint256 tokenId, string[] memory keys, string[] memory texts) public onlyIfPermissed(msg.sender) {
    require(keys.length == texts.length, "tokenIds and txHashes size mismatch");
    for (uint256 i = 0; i < keys.length; ++i) {
      string memory key = keys[i];
      string memory text = texts[i];
      tokenIdToDocumentMap[tokenId][key] = Document(msg.sender, text, block.timestamp);
      emit UpdatedDocument(tokenId, msg.sender, key, text, 0, ""); 
    }
  }
}