modshare: GetRow method

[Wondertan]

Overview

We need the ability to get rows out of EDS for a height. Integration users(cc @Ferret-san) need access to the entire row with parity data. Currently, users resort to fetching full EDS via GetEDS to get a row, which doesn't scale and adds additional complexity.

API

To achieve this, we add the following method to ShareModule.

  GetRow(context.Context,  height uint64, rowIdx int) (shwap.Row, error)

Implementation

The necessary protocol changes have already been implemented, and it's already possible to request Row with Shwap. The remaining work is to plumb support up to the API.

We add and use the new shwap.Getter method:

  GetRow(context.Context, *header.ExtendedHeader, rowIdx int) (shwap.Row, error)

And add implementations to BitswapGetter and CascadeGetter

The BitswapGetter already uses Row fetching to get the EDS, which can be used as an example of how to fetch Rows/

Testing

The feature must be delivered with a Swamp test, ensuring integration test coverage and API breakage protection. The test case should verify that every Q1Q2 row can be fetched and matches the DAH. Besides, we should check that Q3Q4 rows are restricted from fetching.

[walldiss]

Besides, we should check that Q3Q4 rows are restricted from fetching.

What is the motivation for API to be restricted?

[Wondertan]

What is the motivation for API to be restricted?

We don't allow parity namespaces and tail padding for namespace requests. Similalrly here, we don't allow data that doesn't have meaningful data.

[vgonkivs]

GetRow(context.Context, height uint64, rowIdx int) (shwap.Row, error)

The shwap.Row contains only half of the shares in the row. As a result, the high-level API will not function as expected, since users require the full row of shares. This issue can be fixed by caching the extended shares on the client side before returning the result to the user.

[Wondertan]

Two more things:

• Row should define Marshal/UnmarshalJSON
• Row should cache parity data.
  • Currently it recomputes it meaning that serialization will only return the left half instead of full row
  • This is also pretty important optimization, as currently fetching EDS over Bitswap does the compute twice

[Wondertan]

The caching was part of the shwap hardening issue. As there is now another reason to do it, I made an issue for it #3984