Create metadata claim verification process #2
Comments
|
I'm interested in serving on the historians panel. Name: Victor Rortvedt |
|
Very interested in serving on the historians panel too! Name: Philipp Ensinger |
|
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 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. |
|
@dave4506 Either way imo it should be done in a public and visible way maybe via a governance forum like other defi platforms use: Regarding question 4:
(these are just examples, maybe you guys have better ideas) |
|
Name: Song Guo |
Happy to set up a Gnosis Safe once we have a core crew of volunteers.
Awesome - thanks POB team!
I envision three venues for discussion:
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.
Perhaps you could create an invite-only discord channel where we could hammer these details out? |
|
Here is a proposed Claim Verification Process - please review and comment in the doc: https://hackmd.io/T253xfyEQI6xYGXxWdkPVw |
|
^ on that: I like the specificity and the high level process of verifying. Speaking more on getting this going:
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. |
|
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. |
|
Great plan! @vrortvedt Haha youre always superfast at it 😁 if you need some help with airtable be sure to hit me up |
|
@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) |
|
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. |
|
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. |
|
Thanks! |
|
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 |
|
This is my first draft of the new permissioned metadata writer. The
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, "");
}
}
} |
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:
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
The text was updated successfully, but these errors were encountered: