Near2EthProver

[maxzaver]

We need to write a contract that verifies the merkle proofs towards certain transaction outcomes. The specific design of the proofs is discussed here: near/nearcore#2632

[bowenwang1996]

Maybe I misunderstand what code you are talking about, but I don't think Misha wrote any of that code. It would be unfair to attribute potential suboptimalities to him.

[maxzaver]

@mikhailOK used to own nearcore/core/storage/state code between Autumn'19 and Spring'20. This code implements Merkle Patricia Trie and he is very familiar with it. NearProver would need to work with the paths in generated by that code.

[bowenwang1996]

I see. But proofs for transaction outcomes is not stored in state. Maybe you mean something else.

[maxzaver]

I see. But proofs for transaction outcomes is not stored in state. Maybe you mean something else.

Correct. We have two different architectures for proving "events" in Near:

• Proving certain transaction outcome;
• Proving certain state.

For the former we need someone who wrote or worked with merkelization code https://github.com/nearprotocol/nearcore/blob/4713f5f88a7a57d6b5a13ed1057289858d63f134/core/primitives/src/merkle.rs#L28 I guess it is you? So you might be right that @k06a would need to be asking your help instead of @mikhailOK 's.

[k06a]

Could we generate proofs by building Tree/Trie for all outcomes?

[maxzaver]

Could we generate proofs by building Tree/Trie for all outcomes?

I think that would be the best way to do it. Really easy, just read borsh-serialized transaction outcomes and merkelize them, the code is all there.

[bowenwang1996]

@nearmax

Proving certain state.

I think we don't have this exposed properly. See near/nearcore#2076. It might require some effort.

[maxzaver]

Yup, we don't have it exposed. That's why we are going with the transaction outcome.