The simplest evidence standard - superseding EIP1497

[marsrobertson]

EIP 1497: ERC 1497: Evidence Standard · Issue #1497 · ethereum/EIPs · GitHub

I have recently worked on the integration, was looking at code - gtcr/src/pages/factory/deploy.js at 9acd78d79e49cf023c9724b60fd79093faf7af10 · kleros/gtcr · GitHub - even Kleros does not follow strictly Kleros standards.

Here is what I propose instead. Using defaults as much as possible, simplifying.

---

string[] evidence

Keeping an array of evidence.

addEvidence(string ipfshash)

Does exactly what says on the tin.

getEvidenceCount()

Does exactly what says on the tin, Solidity requires this function, otherwise no easy way to retrieve all items.

---

Special filetypes:

• Plain text
• Image
• File: PDF
• File: any other format

.doc, .docx, open office - the list can go an on - we treat them as “any other type” - we encourage PDF.

Counterargument

The existing EIP 1497 covers much more, even though is it called “Evidence Standard” it handles not only the evidence.

[n1c01a5]

string[] public evidence to get a getter.

addEvidence(string ipfshash) => addEvidence(string evidenceID) // or evidenceId to be more generic (could be ipfs / arweave / … / or something centralised even if it’s not recommended…).

Mmm or maybe another name because it can be ambiguous with the evidence id in the smart contract (string[] evidence).

[marsrobertson]

@n1c01a5

could be ipfs / arweave

Of course yes.

BUT

IPFS has namespace, starts with certain characters

arweave has namespace

Example from my mirror blog.

I can be even https:// or any other URI

BUT

If you do something too crazy, then not sure if the front-end will be smart enough to display.

For sure it is smart enough to know if this is IPFS hash / arweave digest / URL.

[n1c01a5]

If you do something too crazy, then not sure if the front-end will be smart enough to display.

Good point.

So we can use something like addEvidence(string _baseURI, string _ID) (like baseURIERC721) so in this case baseURI could be a protocol like ipfs:// or a centralized server.

And after each frontend can whitelist or blacklist some _baseURI.

[marsrobertson]

Why overcomplicate?

Why not a single parameter: STRING

The STRING can be:

• IPFS hash
• arveawe hash
• any URI https://, ftp://, twitter://

But be advised - if you do anything too crazy - the front-end will do NOT know.

Same with the target of the hash: PDF as default. It can be .zip, it can be .docx but anything too crazy and the user will not know.

[n1c01a5]

Yes, you’re right, but the idea was to be able to somehow isolate a hash/multihash.

This would make it possible to ensure the validity of the content, especially for proofs from centralized URIs where the data can be corrupted.

Perhaps we should add an optional field with the (multi)hash and the type of hash function.

The idea might be to have a simple mode where the URI is transmitted, and a more expert mode with the “proof” of the content.

[marsrobertson]

@n1c01a5

proofs from centralized URIs where the data can be corrupted

You mean integrity? Just like consuming JavaScript libraries: Subresource Integrity - Web security | MDN

If someone uses URL as opposed to PDF it means they intentionally want live version as evidence.

Feature, not a bug.

This can cause confusion when the live URL updates in between. Therefore it should be discouraged.

I still think that a single field is simple enough and no need to overcomplicate.

---

@n1c01a5

optional field with the (multi)hash and the type of hash function

Seems like overcomplicating. I actually do not know exactly what do you mean by multihash. My intuitive mental model is not familiar with this term.

In the theme of simplifying, I would pick a default hash function (sha3 or keccak) to help reduce mental bandwidth required to get starred.

[n1c01a5]

Yes, I meant to talk about the integrity of the source.

Here, integrity refers to the content of the source, not whether the content was corrupted between the server and the client.

The problem is how to ensure that the evidence has not been corrupted over time, whether it’s a PDF or any other format, as long as the URI does not contain the (multi)hash.

To draw a parallel with real life, in judicial cases, evidence can be sealed to prevent potential alteration of the evidence.

We need a way to reproduce this.

PS: The multihash allows you to prefix the hash with the type of hashing function used (md5, sha3, keccack256…).

In theory, it could be practical, but the multihash needs to be standardized I mean some protocols have different multihashes with the same hash function / content. IPFS uses its own multihash since it encrypts the data with a kind of Merkle tree called Merkle DAG.

Here is a very good ressource about this topic : IPLD Tutorial | Merkle DAGs: Structuring Data for the Distributed Web | ProtoSchool

[marsrobertson]

@n1c01a5

To draw a parallel with real life, in judicial cases, evidence can be sealed to prevent potential alteration of the evidence.

I was in court 10+ times and chain-of-custody is a joke. Sending .doc documents thay surely were not altered LOL.

Simple workaround

Take a screenshot of the live URL as soon as is published.

Use multiple archiving services. Rumour: https://twitter.com/Pledditor/status/1678295545683558400

RELATED: Default list of archivers

Two domains

• https://legalprintscreen.com/
• http://legalscreenshot.com/

(I may accidentally build a product around it)

additionalContext

JSON file with key-value pairs:

{
	"format": "PDF",
	"hash": "deadbeef",
	"hashFunction": "sha3", 
}

I find it balanced. Not too excessive. If someone wants to include additional context info - this can be infinitely extensible. Just don’t use too crazy stuff, otherwise front-end will not know what to do with it.

DEFAULT for front-end will be to display all key-value pairs.

[n1c01a5]

Do we need format in additionalContext ?

Another point, it’s important to consider the gas cost optimization for Layer 1 (L1).

We might be better served by simply adding a parameter like details, and following a convention such as <hash>, <hash function> to optimize gas cost, without the JSON format.

[marsrobertson]

@n1c01a5

Do we need format in additionalContext ?

Of course we don’t need it.

It was just the example.

I personally wouldn’t trust user provided input, this is the view I’ve shared back in the day:

I just happent o know that Kleros is using some clever tricks to preserve the extension of the file, so I thought:

• IPFS hash alone does not tell the type of the file
• it’s probably the most useful piece of information, whether something is PDF, TXT (plain text) or image

@n1c01a5

Another point, it’s important to consider the gas cost optimization for Layer 1 (L1).

Free market decides.

Kleros on L1 with gas fees - mininal additional info - unless really required.

Kleros on other chains - just pay for the thing.

@n1c01a5

We might be better served by simply adding a parameter like details, and following a convention such as <hash>, <hash function> to optimize gas cost, without the JSON format.

I see this as horrible idea. The whole concept was to simplify - a single parameter string. Then the discussion went into https:// live URLs, integrity of the website… So I thought about addititionalContext that is “catch all” for any additional stuff that you may think of in the future.

Yes, the EIP is dynamic and evolving. We do not know in advance what fields will be useful but by providing facility to add it - futureproofing.

@n1c01a5

following a convention such as <hash>, <hash function>

If we were to optimise for gas AND optimise for live URLs then maybe yes. In the context of EIP and we want to accomplish (simplicity) I find it really bad.

[n1c01a5]

Be careful, the JSON you are proposing is on-chain, this could quickly consume a very significant portion of gas.

BTW, I didn’t fully understand the points you were making but to avoid any ambiguity.

Here’s what I suggest:

It’s a function addEvidence(string _URI, string _details) after the _details field is free which allows for some flexibility.

Afterward, the standard doesn’t have to decide right away on the format of _details and it’s experimentation that can impose the standard of this specific param.

Another point, I talked about this event Evidence(Arbitrator indexed _arbitrator, uint indexed _evidenceGroupID, address indexed _party, string _evidence) not about the MetaEvidence event.

For me, the params Arbitrator indexed _arbitrator, uint indexed _evidenceGroupID, address indexed _party can be removed from the EIP for simplicity (it’s more developer friendly to use state var but consume much more gas than event).

But of course, we need to link any evidences to a specific the dispute.

We agree that you want to change this Solidity event to a state variable, right?

But I’m not totally convinced to move to state variable for the gas cost.

P.S. I’m not a big fan of the naming additionalContext , it’s not conventional, but _details is also not really explicit. _metaDescription or _headers could be interesting to discuss.

P.S 2 : Wouldn’t it be more convenient to continue the discussion on ERC 1497: Evidence Standard · Issue #1497 · ethereum/EIPs · GitHub, don’t you think?

See ERC 1497: Evidence Standard · Issue #1497 · ethereum/EIPs · GitHub , I added a comment.

[marsrobertson]

@n1c01a5

It’s a function addEvidence(string _URI, string _details) after the _details field is free which allows for some flexibility.

Why using _underscores? Asked the AI… Fine with me.

• My initial proposal was to use just the IPFS hash, for example: Qme7FPNUB5LodubXPv8u1STixYmwygY5VDjMVPEUtQMrAW/2023-06-16-kleros-basex-policies-generic.pdf

• Optionally we can use the protocol at the beginning: ipfs://Qme7FPNUB5LodubXPv8u1STixYmwygY5VDjMVPEUtQMrAW/2023-06-16-kleros-basex-policies-generic.pdf

• Definitely not the full URL with gateway: https://ipfs.kleros.io/ipfs/Qme7FPNUB5LodubXPv8u1STixYmwygY5VDjMVPEUtQMrAW/2023-06-16-kleros-basex-policies-generic.pdf

@n1c01a5

Be careful, the JSON you are proposing is on-chain, this could quickly consume a very significant portion of gas.

@marsrobertson

Free market decides.

Kleros on L1 with gas fees - mininal additional info - unless really required.

I see no issue with it. Of course it consumes gas, feature not a bug.

If that is a concern, rather than submitting JSON structure in plain test, we can submit yet another IPFS… This is what Kleros is doing at the moment. Loads of addtional data is stored in JSON that is posted to IPFS.

@n1c01a5

We agree that you want to change this Solidity event to a state variable, right?

I suggest simplifying the evidence standard to have a really simple structure…

@marsrobertson

string[] evidence

Keeping an array of evidence.

addEvidence(string ipfshash)

Does exactly what says on the tin.

To have the entire array of evidence available on chain, easily accessible - make sense to me.

We can also emit an event if that is practical.

@n1c01a5

P.S 2 : Wouldn’t it be more convenient to continue the discussion on ERC 1497: Evidence Standard · Issue #1497 · ethereum/EIPs · GitHub, don’t you think?

This is old content from 2018 and 2019… As long as we are on the same page I’m OK either way.

info / details / context / extra / data / blob / params

It seems like there might be some tiny difference when deploying… I don’t think golfing the variable names is a good use of out mental energy. Let’s just agree onto something.

[n1c01a5]

Regarding the last point, I was not talking about the length of the variable name but about its content .

P.S I will be at the ETHCC Agora event, we could talk about it in person, it would probably be simpler

[marsrobertson]

@n1c01a5

I will be at the ETHCC Agora event

Sure. Face to face. Humans evolved in communities, our neural nets are wired to recognise faces… I don’t think we ever met IRL

I like public forum - more inclusive, public, transparent, open-source - but I’m also aware that our discussion went into distant tangents and nuanced point.

My core intention is to simplify

The moment we start talking about “metahash” I become confused as it is non-obvious.

Current state of my thinking

1st parameter is the URI of the evidence, this can be any protocol:

• ipfs://
• arweave://
• bitcoin:// (inscriptions)
• https://
• ftp://

There are no limits, but if you use something “too crazy” the front-end may not know how to interpret it.

2nd parameter can be called metadata (or info / details / context / extra / data / blob / params)

It can be either the on-chain JSON key-value data structure or, in case it grows too large and gas cost is the concern - it can be a JSON file uploaded to IPFS, or any other service

My personal preference is towards IPFS because it is well-established, well-adopted standard.

Someone could in theory submit https:// evidence and then https:// metadata but it would be counterproductive, confusing, potentially misleading. I don’t want to stop such behaviour, if someone wants to do weird stuff - it’s their own conscious strategy, they may have some genuine reasons to do it.

I think that complexity of:

• plain text JSON available on-chain
• plain text JSON as IPFS file

Is relatively simple, it is much simpler that existing evidence standard

Nice to have / good to know

Maybe someone has time / energy / willingness to run the analysis of all the existing cases and all the existing evidence.

That would be a valuable data point to see what is used in real-life. In that way we could see what are the common patterns and which parts of the existing standard are ignored.

Suggested fields for metadata

• Format (to quickly display on the front-end whether it is PDF of image)
• Date (sometimes creation date is not equal to publish date)
• Hash
• Hashing algorithm (optional, we can just stick to default hashing function)

3rd party services

I happen to own two domains:

• https://legalprintscreen.com/
• http://legalscreenshot.com/

It is possible to build some standard around it as well, and integrate with other archiving services

• https://archive.org/
• https://archive.ph/

Not just for Kleros but for justice in real-life, loads of legal dudes are still sending .doc Word files that are surely not altered in the process LOL.

Tangent warning

“statement of truth” VS “statement under oath”

Submitting fake / fradulent / misleading evidence in real life can be seen as Perverting the course of justice - Wikipedia

In the UK legal system it is up to a lifetime in prison. In Kleros courts you create an anon account and can cause confusion / chaos… As a part of metadata there could be yet another field:

• Oath - me recording 10 seconds video saying “truth, all the truth, nothing but the truth”

Diversity as competetive advantage

Kindly welcoming other points of view