Cache hash outputs

[musalbas]

We can likely optimize the computation of row/col roots by up to 2x if we cache the outputs of leafs, because right now we are hashing all the data chunks twice, once to compute the row roots, and once to compute the col roots.

[Wondertan]

Additionally, celestia-node or any other rsmt2d consumer using EDS would benefit from caching the proofs along with making them accessible through API.

[Wondertan]

Otherwise, users have to come up with hacks to gain performance benefits from caching. See: https://github.com/celestiaorg/celestia-node/pull/2429/files

[musalbas]

Maybe this should actually just be implemented in the (tree)hasher implementation rather than rsmt2d. Or make a cached hasher implementation

[Wondertan]

Do you mean multihash hasher?

[musalbas]

I was thinking something like https://github.com/celestiaorg/nmt/blob/master/hasher.go, but I haven't thought much about what the right place to abstract it is.

…

On Mon, 7 Aug 2023, 20:37 Hlib Kanunnikov, ***@***.***> wrote: Do you mean multihash hasher? — Reply to this email directly, view it on GitHub <#260 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGOEBMIUAFJIGBG4WLDMLTXUE7WPANCNFSM6AAAAAA3HCQYI4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Wondertan]

This hasher is global, while proofs are per EDS. The hasher could store a eds->proofs map, but I don't think it should be responsible for that. Instead, the EDS itself should keep a reference to a built tree.